"Fred L. Drake, Jr." wrote: > > M.-A. Lemburg writes: > > I am not sure whether this is the right way to approach this > > problem, though, since it affects all extensions -- not only > > ones using Unicode. > > Given that unicodeobject.h defines many macros and size-sensitive > types in the public API, I don't see any way around this. If the API > always used UCS4 (including in the macros), or defined both UCS2 and > UCS4 versions of everything affected, then we could get around it. > That seems like a high price to pay. I think Guido suggested using macros to turn the Unicode APIs into e.g. PyUnicodeUCS4_Encode() vs. PyUnicodeUCS2_Encode(). That would prevent loading of non-compatible extensions using Unicode APIs (it doesn't catch the argument parser usage, though, e.g. "u"). Perhaps that's the way to go ?! -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4