As usual, I agree with you Pawel :)

That said, I don't have a lot of "handcrafted tweaks for str/unicode
aliasing", so it's easy for me to dismiss that negative.

To me, your proposal sounds elegant, but I am open to consensus.


On Sat, Sep 17, 2016 at 3:13 AM, Pawel Jasinski <>

> hi,
> 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
> jython).
> Thanks to Kuno (see, 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.
> cheers,
> --pawel
> _______________________________________________
> Ironpython-users mailing list
Ironpython-users mailing list

Reply via email to