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

Eli Bendersky eliben at gmail.com
Fri Jan 27 17:44:02 CET 2012

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?

I guess there's no real problem with leaving it accessible, as long as it's clear that the API may have changed between releases. I.e. when a package "graduates" and is also left accessible through preview, it should obviously be just a pointer to the same package, so if the API changed, code that imported it from preview in a previous release may stop working.

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 :)

Agreed, I will change this

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 :-)

I agree that it's speculative, and would recommend to decouple the two PEPs. They surely can live on their own and aren't tied. If PEP 407 gets accepted, this section can be reworded appropriately.

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?

Good point.

Eli

More information about the Python-Dev mailing list