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

[Michael Foord]

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