[Python-Dev] PEP 408 -- Standard library __preview__ package
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 , 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?
The point about pickling is one good reason, minimising code breakage
(due to package name changing) is another.
>> 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?
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.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