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.jasin...@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@python.org > https://mail.python.org/mailman/listinfo/ironpython-users > >
_______________________________________________ Ironpython-users mailing list Ironpython-users@python.org https://mail.python.org/mailman/listinfo/ironpython-users
