Larry Hastings:
> First and foremost: turning off Py_USING_UNICODE *breaks the build*
> on Windows. The following list of breakages were all fixed with
> judicious applications of #ifdef Py_USING_UNICODE:
> * The implementation of "multi-byte codecs" (CJK codecs) implicitly
> assumes that they can use all the Unicode facilities. So all the
> files in "Modules/cjkcodecs" fail to build.
> * Obviously, the Unicode string object depends on Unicode support,
> so Objects/unicode* doesn't build.
> * There are several spots in the code that need to handle Unicode
> strings in some slightly special way, and assume Unicode is turned
> on. E.g.:
> * Modules/posixmodule.c, posix__getfullpathname(), line 1745
> * same file, posix_open(), starting on line 5201
> * Objects/fileobject.c, open_the_file(), starting on line 158
> * _winreg.c, Py2Reg(), starting on lines 724 and 777
I'm probably responsible for some of the breakage when adding
Unicode file name support to Python. Windows is a Unicode based
operating system and I expect Unicode calls will eventually infest the
code base to a greater extent than currently. Requiring each
modification that adds a Unicode feature to be safe with
Py_USING_UNICODE turned off will add to the implementation effort for
that feature. I'd prefer to drop support for turning off
Py_USING_UNICODE in Windows specific code. Well, since it is currently
broken, document that it isn't supported. Other platforms may need to
continue allowing non Py_USING_UNICODE builds.
Neil
--
http://mail.python.org/mailman/listinfo/python-list
