This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients ajaksu2, amaury.forgeotdarc, collinwinter, eric.smith, ezio.melotti, jafo, jimjjewett, lemburg, orivej, pitrou, vstinner
Date 2009-06-02.17:17:38
SpamBayes Score 2.02809e-08
Marked as misclassified No
Message-id <1243963193.5426.42.camel@localhost>
In-reply-to <>
> 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

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.
Date User Action Args
2009-06-02 17:17:43pitrousetrecipients: + pitrou, lemburg, collinwinter, jafo, jimjjewett, amaury.forgeotdarc, vstinner, eric.smith, ajaksu2, orivej, ezio.melotti
2009-06-02 17:17:41pitroulinkissue1943 messages
2009-06-02 17:17:39pitroucreate