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

Nick Coghlan ncoghlan at gmail.com
Sat Jan 28 10:18:01 CET 2012

On Sat, Jan 28, 2012 at 6:38 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> I don't have an opinion on whether this is an argument for rejecting
> the PEP or for rewriting it (specifically, seriously beefing up the
> "after trying it, maybe we won't want to maintain it" rationale).  I
> also think that if "we need to try it to decide if the maintenance
> burden is acceptable" is a rationale, the name "__experimental__"
> should be seriously reconsidered as more accurately reflecting the
> intended content of the package.

I think it's an argument for rewriting it (and, as you point out,
perhaps reverting to __experimental__ as the proposed name). Eli
started from a draft I wrote a while back and my own thinking on the
topic wasn't particularly clear (in fact, it's only this thread that
has really clarified things for me).

The main thing I've realised is that the end user benefits currently
discussed in the PEP are really about the importance of a robust
*standard library*. They aren't specific to the new namespace at all -
that part of the rationale is really only needed to counter the
predictable "who cares about the standard library, we can just use
PyPI!" responses (and the answer is, "lots of people that can't or
won't use PyPI modules for a wide range of reasons").

The only reason to add a new double-underscore namespace is to address
*core developer* concerns in cases where we're *almost* sure that we
want to add the module to the standard library, but aren't quite
prepared to commit to maintaining it for the life of the 3.x series
(cf. 2.x and the ongoing problems we had with keeping the bsddb module
working properly, especially before Jesus Cea stepped up to wrangle it
into submission).

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


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

More information about the Python-Dev mailing list