[Python-Dev] PEP 408 -- Standard library preview package (original) (raw)

Michael Foord fuzzyman at voidspace.org.uk
Fri Jan 27 16:27:36 CET 2012

On 27/01/2012 15:09, Antoine Pitrou wrote:

On Fri, 27 Jan 2012 15:21:33 +0200 Eli Bendersky<eliben at gmail.com> wrote:

Following an earlier discussion on python-ideas [1], we would like to propose the following PEP for review. Discussion is welcome. The PEP can also be viewed in HTML form at http://www.python.org/dev/peps/pep-0408/ A big +1 from me.

Assuming the module is then promoted to the the standard library proper in release 3.X+1, it will be moved to a permanent location in the library::

import example And importing it from _preview_ will no longer work. Why not leave it accessible through preview too?

+1

The point about pickling is one good reason, minimising code breakage (due to package name changing) is another.

Michael

Benefits for the core development team --------------------------------------

Currently, the core developers are really reluctant to add new interfaces to the standard library. A nit, but I think "reluctant" is enough and "really" makes the tone very defensive :) Relationship with PEP 407 ========================= PEP 407 proposes a change to the core Python release cycle to permit interim releases every 6 months (perhaps limited to standard library updates). If such a change to the release cycle is made, the following policy for the _preview_ namespace is suggested: * For long term support releases, the _preview_ namespace would always be empty. * New modules would be accepted into the _preview_ namespace only in interim releases that immediately follow a long term support release. Well this is all speculative (due to the status of PEP 407) but I think a simpler approach of having a preview namespace in all releases (including LTS) would be easier to handler for both us and our users. People can refrain from using anything in preview if that's what they prefer. The naming and the double underscores make it quite recognizable at the top of a source file :-) Preserving pickle compatibility ------------------------------- A pickled class instance based on a module in _preview_ in release 3.X won't be unpickle-able in release 3.X+1, where the module won't be in _preview_. Special code may be added to make this work, but this goes against the intent of this proposal, since it implies backward compatibility. Therefore, this PEP does not propose to preserve pickle compatibility. Wouldn't it be a good argument to keep preview.XXX as an alias? Regards Antoine.

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk

-- http://www.voidspace.org.uk/

May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html

More information about the Python-Dev mailing list