[Python-Dev] PEP 408 -- Standard library __preview__ package

Antoine Pitrou solipsis at pitrou.net
Fri Jan 27 16:09:34 CET 2012

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?

> 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?



More information about the Python-Dev mailing list