Dirkjan Ochtman wrote: > On Mon, May 18, 2009 at 12:07 AM, "Martin v. Löwis" <mar...@v.loewis.de> > wrote: >> I fail to see the relationship, so: no effect that I can see. >> >> Why do you think that optimization efforts could be related to >> the PEP 384 proposal? > > 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.
Ah. It's exactly the opposite: The purpose of the PEP is not to lock the data structures down, but to allow more flexible evolution of them - by completely hiding them from extension modules. Currently, any data structure change must be weighed for its impact on binary compatibility. With the PEP, changing structures can be done fairly freely - with the exception of the very few structures that do get locked down. In particular, the list of header files that you quoted precisely contains the structures that can be modified with no impact on the ABI. I'm not aware that any of the structures that I propose to lock would be relevant for optimization - but I might be wrong. If so, I'd like to know, and it would be possible to add accessor functions in cases where extension modules might still legitimately want to access certain fields. Certain changes to the VM would definitely be binary-incompatible, such as removal of reference counting. However, such a change would probably have a much wider effect, breaking not just binary compatibility, but also source compatibility. It would be justified to call a Python release that makes such a change 4.0. Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list
