[Python-Dev] PEP 384: Defining a Stable ABI (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Mon May 18 01:04:21 CEST 2009

Dino Viehland wrote:

Dirkjan Ochtman wrote:

It would seem to me that optimizations are likely to require data structure changes, for exactly the kind of core data structures that you're talking about locking down. But that's just a high-level view, I might be wrong.

In particular I would guess that ref counting is the biggest issue here. I would think not directly exposing the field and having inc/dec ref Functions (real methods, not macros) for it would give a lot more ability to change the API in the future.

In the context of optimization, I'm skeptical that introducing functions for the reference counting would be useful. Making the INCREF/DECREF macros functions just in case the reference counting goes away is IMO an unacceptable performance cost.

Instead, such a change should go through the regular deprecation procedure and/or cause the release of Python 4.0.

It also might make it easier for alternate implementations to support the same API so some modules could work cross implementation - but I suspect that's a non-goal of this PEP :).

Indeed :-) I'm also skeptical that this would actually allow cross-implementation modules to happen. The list of functions that an alternate implementation would have to provide is fairly long.

The memory management APIs in particular also assume a certain layout of Python objects in general, namely that they start with a header whose size is a compile-time constant. Again, making this more flexible "just in case" would also impact performance, and probably fairly badly so.

Other fields directly accessed (via macros or otherwise) might have similar problems but they don't seem as core as ref counting.

Access to the type object reference is probably similar. All the other structs are used "directly" in C code, with no accessor macros.

Regards, Martin

More information about the Python-Dev mailing list