[issue1943] improved allocation of PyUnicode objects

[Antoine Pitrou]

Antoine Pitrou <pitrou at 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 <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________