Author loewis
Recipients gvanrossum, lemburg, loewis, r.david.murray, scoder, stutzbach, vstinner, zooko
Date 2010-05-08.13:07:45
SpamBayes Score 1.2648e-06
Marked as misclassified No
Message-id <1273324068.67.0.0793338480532.issue8654@psf.upfronthosting.co.za>
In-reply-to
Content
I propose a different approach:

1. add a flag to PyModuleDef, indicating whether the module was built in UCS-2 or UCS-4 mode. Then let the interpreter refuse the load the module, instead of having the dynamic linker do so.
2. provide a mode for the header files where Py_UNICODE is not defined. add another flag to PyModuleDef indicating whether that mode was used when compiling the extension.

Module authors then can make a choice whether or not to refer to the Unicode internal representation in their module. If they do, a UCS-2 version won't load into a UCS-4 interpreter. If they don't refer to Py_UNICODE at all, the module can be used across the two modes.

There is a slight risk that a module may already crash before calling PyModule_Create. To prevent that, we need to specify that no Unicode API must be used before calling PyModule_Create.
History
Date User Action Args
2010-05-08 13:07:49loewissetrecipients: + loewis, lemburg, gvanrossum, zooko, scoder, vstinner, stutzbach, r.david.murray
2010-05-08 13:07:48loewissetmessageid: <1273324068.67.0.0793338480532.issue8654@psf.upfronthosting.co.za>
2010-05-08 13:07:46loewislinkissue8654 messages
2010-05-08 13:07:45loewiscreate