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 lemburg
Recipients ajaksu2, amaury.forgeotdarc, collinwinter, eric.smith, ezio.melotti, jafo, jimjjewett, lemburg, orivej, pitrou, vstinner
Date 2009-06-02.22:25:53
SpamBayes Score 1.3549162e-12
Marked as misclassified No
Message-id <4A25A6EE.9020505@egenix.com>
In-reply-to <1243963193.5426.42.camel@localhost>
Content
Antoine Pitrou wrote:
> Antoine Pitrou <pitrou@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.

As soon as they want to do C-level sub-typing, a change from
PyObject to PyVarObject will break their code in non-trivial ways.

>> 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.

Header files *are* the API reference.

There are many instances where they include things that are only
meant to be used internally by the interpreter, but these are
carefully documented in the header files.

>> 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.

It would be foolish to break such compatibility for the sake of some
really minor performance win.

Python's main focus is flexibility, not speed. Your proposed change
makes it a lot harder to tap into the available flexibility, since
sub-typing of PyVarObjects is non-trivial.

> (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)

Well, since you don't appear to count the many attempts to get
slicing-by-reference into the base type as proof that such ideas
do have use-cases, I've posted an example implementation which
provides such a sub-type.

It's easy to extend to all the use cases I've mentioned so far.
History
Date User Action Args
2009-06-02 22:25:58lemburgsetrecipients: + lemburg, collinwinter, jafo, jimjjewett, amaury.forgeotdarc, pitrou, vstinner, eric.smith, ajaksu2, orivej, ezio.melotti
2009-06-02 22:25:57lemburglinkissue1943 messages
2009-06-02 22:25:53lemburgcreate