This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients Robin.Schreiber, belopolsky, loewis, skrah
Date 2013-08-07.09:21:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1375867306.55.0.91837715789.issue15787@psf.upfronthosting.co.za>
In-reply-to
Content
"""
Regarding the suggestion of separating PEP3121 and PEP384. It might be true that datetime and other modules do not benefit directly from PEP 384, however it is still a fact that the stdlib modules should be seen as a set of reference modules, that are all implemented in a way that complies with the implementation fo the xxmodules.
I have talked with Martin von Löwis about this, and as far as I understood him correctly he also sees the PEP384 refactoring applied to the whole stdlib as a necessary "signal" to other developers to refactor their modules accordingly.
""" (Robin Schreiber, #15390, msg177274)

MvL have recently confirmed this on python-dev: "Choice of supporting PEP 384 was deliberate. It will change all types into heap types, which is useful for multiple-interpreter support and GC."

Accordingly, I've changed the title of this issue and added a few PEP 384 only dependencies.
History
Date User Action Args
2013-08-07 09:21:46belopolskysetrecipients: + belopolsky, loewis, skrah, Robin.Schreiber
2013-08-07 09:21:46belopolskysetmessageid: <1375867306.55.0.91837715789.issue15787@psf.upfronthosting.co.za>
2013-08-07 09:21:46belopolskylinkissue15787 messages
2013-08-07 09:21:45belopolskycreate