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

[Guido van Rossum]

On Sat, Jan 28, 2012 at 5:04 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> On 28 January 2012 09:18, Nick Coghlan <ncoghlan at gmail.com> wrote:
>
>> It's basically us saying to Python users "We're explicitly flagging
>> this PyPI module for inclusion in the next major Python release. We've
>> integrated it into our build process, test suite and binary releases,
>> so you don't even have to download it from PyPI in order to try it
>> out, you can just import it from the __preview__ namespace (although
>> you're still free to download it from PyPI if you prefer - in fact, if
>> you need to support multiple Python versions, we actively recommend
>> it!). There's still a small chance this module won't make the grade
>> and will be dropped from the standard library entirely (that's why
>> it's only a preview), but most likely it will move into the main part
>> of the standard library with full backwards compatibility guarantees
>> in the next release".
>
> +1.

Hm. You could do this just as well without a __preview__ package. You
just flag the module as experimental in the docs and get on with your
life.

We have some experience with this in Google App Engine. We used to use
a separate "labs" package in our namespace and when packages were
deemed stable enough they were moved from labs to non-labs. But the
move always turned out to be a major pain, causing more breakage than
we would have had if we had simply kept the package location the same
but let the API mutate. Now we just put new, experimental packages in
the right place from the start, and put a loud "experimental" banner
on all pages of their docs, which is removed once the API is stable.

There is much less pain now: while incompatible changes do happen for
experimental package, they are not frequent, and rarely
earth-shattering, and usually the final step is simply removing the
banner without making any (incompatible) changes to the code. This
means that the final step is painless for early adopters, thereby
rewarding them for their patience instead of giving them one final
kick while they sort out the import changes.

So I do not support the __preview__ package. I think we're better off
flagging experimental modules in the docs than in their name. For the
specific case of the regex module, the best way to adoption may just
be to include it in the stdlib as regex and keep it there. Any other
solution will just cause too much anxiety.

-- 
--Guido van Rossum (python.org/~guido)