[Python-Dev] PEP 408 -- Standard library __preview__ package
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 , we would like to
> propose the following PEP for review. Discussion is welcome. The PEP
> can also be viewed in HTML form at
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