[Python-Dev] PEP 384: Defining a Stable ABI
"Martin v. Löwis"
martin at v.loewis.de
Sun May 17 19:04:21 EDT 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
> 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.
More information about the Python-list