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 -- http://mail.python.org/mailman/listinfo/python-list
