Antoine Pitrou <pit...@free.fr> added the comment: > You cannot simply recompile your code and have it working.
Who is "you"? People doing mundane things with PyUnicodeObjects certainly can, assuming they use the macros for any member access. > Please note that all type objects documented in the header files > not explicitly declared for private use only, are in fact > public APIs. If the datatype layout is not publicly documented in the API reference, it certainly seems to be a non-public part of the API. That's why we have macros for member access, instead of letting people access members directly. The fact that my patch doesn't touch any part of the C sources except for the unicode implementation itself seems to support this view as well: people have been using the macros because they understand the actual layout shouldn't be relied upon. > You need access to those type objects in order to > be able to subclass them. As is needed for every other core object whose layout is nevertheless changed now and then... I think it should be expected that any code relying on low-level implementation specifics can break now and then. Changing low-level implementation specifics is often a prerequisite for improving things and it would be foolish to make a promise that we guarantee 100% compatibility at that level. (we could of course strengthen the rules for unicode if it was demonstrated that there are several popular instances of subclassing unicode in a C extension. However, I haven't seen any such examples) > Note that the Unicode implementation takes great care not to hide > this binary incompatibility - by remapping all APIs to include the > UCS2/UCS4 hint in the exported name. That's because there are UCS2 and UCS4 builds *of the same interpreter version*, and people are not necessarily aware of there being a difference. Such variability is not what we are talking about here. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1943> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
