Guido van Rossum <guido@python.org> writes: > Really? If I am only using the published APIs and not peeking > directly inside the Unicode object, why should I care about its > internal lay-out? The safeguard is to tell apart module that use Unicode objects from modules which don't. If a module uses Unicode objects, it might be using PyUnicode_AS_UNICODE. Unfortunately, this does not result in a symbol reference, so using a module that only uses PyUnicode_AS_UNICODE would break if it was compiled for the wrong width of Py_UNICODE. Mangling all Unicode functions is the best safeguard we could find to protect against this case. It is still possible to cheat that, but it is unlikely that somebody breaks the safeguard by accident. Likewise, it is unlikely that a single platform has builds for two different Py_UNICODE sizes simultaneously, so the safeguard does not add additional burden, either. Regards, Martin
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