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

[Eli Bendersky]

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