Message105286
| Author |
lemburg |
| Recipients |
gvanrossum, lemburg, loewis, r.david.murray, scoder, stutzbach, vstinner, zooko |
| Date |
2010年05月08日.13:15:28 |
| SpamBayes Score |
4.0967842e-07 |
| Marked as misclassified |
No |
| Message-id |
<4BE563ED.1040809@egenix.com> |
| In-reply-to |
<1273324068.67.0.0793338480532.issue8654@psf.upfronthosting.co.za> |
| Content |
Martin v. Löwis wrote:
>
> Martin v. Löwis <martin@v.loewis.de> added the comment:
>
> 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.
+1
We could then get rid off the API renaming altogether. |
|