I have noticed that the long standing string/unicode subject surfaced again
in chat (#1414)
For long time I was convinced that jython uses the same strategy as
ironpython in regards to str/unicode aliasing. There was hope to get
cpython compatibility at similar level as jython (e.g. django works under

Thanks to Kuno (see https://github.com/IronLanguages/main/pull/1331), I was
corrected. jython made a change in 2.5, so str and unicode are distinct
types. I believe this change alone made a big difference with respect to
their cpython compatibility.

Now the question is what stops us from doing the same?
We could have a distinctive type entry for str and unicode, but keep the
existing implementation which uses .net string as storage for byte strings.
The arguments passed to .net will be mapped exactly as they are today.
The results coming back from .net would surface as unicode (which they are).

Marcus expressed concerns "shipping our own string implementation would be
somehow overkill, and could severely hurt performance when interfacing with
.NET. I think it's not worth the effort for 2.x"
Marcus, does your concern still apply if the implementation follows the
"distinctive type entry" idea?

The positives I can see:
- able to use things out of PyPI without tweaking
- no patching of stdlib
- no time spend on investigating another bug report which turns out to be
str/unicode alias. I would never expect it to cause stack overflow (#1414).
- chance to move forward with ironclad - the str/unicode aliasing is the
biggest road block when trying to fix numpy integration

The negatives I am aware of:
- this has a potential to break existing ironpython code which already has
a lot of handcrafted tweaks for str/unicode aliasing. This would have to be
taken out.
- working on this, would take resources from working on 3

I am sure, that as usually I am overlooking and/or trivializing something,
so please speak up.

Ironpython-users mailing list

Reply via email to