Shrinky-dink Python (also, non-Unicode Python build is broken)

[Neil Hodgson]

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