On Sun, Jan 29, 2012 at 3:15 AM, Guido van Rossum <gu...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
