[Ironpython-users] string/unicode

[Tim Orling]

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.

--Tim

On Sat, Sep 17, 2016 at 3:13 AM, Pawel Jasinski <pawel.jasinski at gmail.com>
wrote:

> 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 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.
>
> cheers,
> --pawel
>
>
> _______________________________________________
> Ironpython-users mailing list
> Ironpython-users at python.org
> https://mail.python.org/mailman/listinfo/ironpython-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20160917/77906e44/attachment.html>