On May 7, 2005, at 5:09 PM, M.-A. Lemburg wrote: > However, I don't understand all the excitement > about Py_UNICODE: if you don't like the way this Python > typedef works, you are free to interface to Python using > any of the supported encodings using PyUnicode_Encode() > and PyUnicode_Decode(). I'm sure you'll find one that > fits your needs and if not, you can even write your > own codec and register it with Python, e.g. UTF-32 > which we currently don't support ;-)
My concerns about Py_UNICODE are completely separate from my frustration that the documentation is wrong about this type. It is much more important that the documentation be correct, first, and then we can discuss the reasons why it can be one of two values, rather than just a uniform value across all python implementations. This makes distributing binary extension modules hard. It has become clear to me that no one on this list gives a *%&^ about people attempting to distribute binary extension modules, or they would have cared about this problem, so I'll just drop that point. However, somehow, what keeps getting lost in the mix is that --enable-unicode=ucs2 is a lie, and we should change what this configure option says. Martin seems to disagree with me, for reasons that I don't understand. I would be fine with calling the option utf16, or just 2 and 4, but not ucs2, as that means things that Python doesn't intend it to mean. -- Nick _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
