Author belopolsky
Recipients Robin.Schreiber, asvetlov, belopolsky, loewis, pitrou
Date 2012-09-10.23:29:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1347319742.1.0.87140110608.issue15390@psf.upfronthosting.co.za>
In-reply-to
Content
I would like to split this issue to separate PEP 3121 changes from PEP 384.  PEP 3121 state cleanup implementation is clearly an improvement "from a resource management point of view."  On the other hand, I don't see much benefit for the datetime module from using a stable ABI.  Unless I am missing something, PEP 384 is primarily benefiting 3rd party developers who distribute binary modules that should run under multiple Python versions.  ABI stability is not a concern for the stdlib modules.

On the other hand, the price for multi-version support is rather steep.  Statically allocated types are more efficient.  For example, with static types, PyDate_CheckExact() is a simple macro that expands into a dereference and a pointer comparison - a couple of instructions at the CPU level.  On the other hand, with a proposed patch, it will involve a function call to locate the module (PyState_FindModule), followed by another function call to locate the state (PyModule_GetState) and several more dereferences that may lead to cache misses and other pessimizations.

There is an important behavior change related to multiple interpreters.  Currently dates created by different interpreters have the same type.  With the proposed change they will have different types.  I don't think this is desirable.

In short, let's go in baby steps.  Let's implement PEP 3121 cleanup first and start a debate on the role of PEP 384 in stdlib.
History
Date User Action Args
2012-09-10 23:29:02belopolskysetrecipients: + belopolsky, loewis, pitrou, asvetlov, Robin.Schreiber
2012-09-10 23:29:02belopolskysetmessageid: <1347319742.1.0.87140110608.issue15390@psf.upfronthosting.co.za>
2012-09-10 23:29:01belopolskylinkissue15390 messages
2012-09-10 23:29:00belopolskycreate