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

[Nick Coghlan]

On Sun, Jan 29, 2012 at 3:15 AM, Guido van Rossum <guido at python.org> wrote:
> 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.

I'm willing to go along with that (especially given your report of
AppEngine's experience with the "labs" namespace).

Can we class this as a pronouncement on PEP 408? That is, "No to
adding a __preview__ namespace, but yes to adding regex directly for
3.3"?

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia