I think it is a misinterpretation that this topic goes away with Python3. Both
Python2 and Python3 provide *two* string types. Hence, having a second string
type in IronPython would certainly help Python2 compatibility as well as
Python3 compatibility.
I don't agree with your statement about .NET interop. In .NET interop you need
to have unicode strings in any case, and byte strings need to be converted.
Hence, handling would probably have to happen like that:
- The Python2 way would be to convert the byte string on-the-fly to a unicode
string by decoding it with the default encoding. Strings returned from a .NET
component will be unicode. Additional thoughts needs to go into handling of
ref-ed string arguments. With the hidden on-the-fly conversion, you also loose
referential integrity, which might lead to unexpected behaviour in some special
cases.
- The Python3 way would be to insist on unicode strings and throw some sort of
a "wrong argument type" error. But in Python3 mode, string literals are unicode
anyway, so most users won't notice the change.
I have no clear opinion whether System.String as underlying storage
implementation for byte strings is a good idea. It certainly would provide some
optimization possibilities in the conversion case for ASCII content.
In conclusion, I think that this conversion is a non-trivial amount of work
that mostly helps the compatibility with the Python standard library, but has
some serious issues (backwards compatibility, maybe performance) for when
accessing .NET code in Python2 mode. But it is still worth considering.
Kuno
_______________________________________________
Ironpython-users mailing list
Ironpython-users@python.org
https://mail.python.org/mailman/listinfo/ironpython-users
