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

[Nick Coghlan]

On Sat, Jan 28, 2012 at 6:43 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> This PEP only makes sense if we assume that __preview__.spam and spam *will*
> be different, even if only in minor ways, and that there might not even be a
> spam. There should be no expectation that every __preview__ module must
> graduate, or that every standard library module must go through __preview__.
> If it is stable and uncontroversial, __preview__ adds nothing to the
> process.

Yes, the PEP already points to lzma as an example of a module with a
sufficiently obvious API that it didn't need to go through a preview
round.

> Keeping __preview__.spam around after graduation is, I believe, actively
> harmful. It adds complexity to the developer's decision-making process
> ("Should I import spam from __preview__, or just import spam? What's the
> difference?"). It gives a dangerous impression that code written for
> __preview__.spam will still work for spam.

Yes, this was exactly the reasoning behind removing the names from
__preview__ namespace when the modules graduated. It sets a line in
the sand: "An API compatibility break is not only allowed, it is 100%
guaranteed. If you are not prepared to deal with this, then you are
*not* part of the target audience for the __preview__ namespace. Wait
until the module reaches the main section of the standard library
before you start using it, or else download a third party supported
version with backwards compatibility guarantees from PyPI. The
__preview__ namespace is not designed for anything that requires long
term support spanning multiple Python version - it is intended for use
in single version environments, such as intranet web services and
student classrooms"

> I would go further and suggest that __preview__ be explicitly called
> __unstable__. If that name is scary, and it frightens some users off, good!

Hmm, the problem with "unstable" is that we only mean the *API* is
unstable. The software itself will be as thoroughly tested as
everything else we ship.

> I think the PEP needs more use-cases on who might use __preview__.spam, and
> why. These come to my mind:
>
> * if you don't care about Python 3.x+1, then there is no reason not to
>  treat Python 3.x's __preview__.spam as stable;
>
> * rapid development proof-of-concept software ("build one to throw away")
>  can safely use __preview__.spam, since they are expected to be replaced
>  anyway;
>
> * one-use scripts;
>
> * use at the interactive interpreter;
>
> * any other time where forward-compatibility is not required.

A specific list of use cases is a good idea.

I'd add a couple more:

* in a student classroom where the concept of PyPI and third party
packages has yet to be introduced

* for an intranet web service deployment where due diligence adds
significant overhead to any use of third party packages

> I am reminded of the long, often acrimonious arguments that took place on
> Python-Dev a few years back about the API for the ipaddr library. A lot of
> the arguments could have been short-circuited if we had said "putting ipaddr
> into __preview__ does not constitute acceptance of its API".

Yep, there's a reason 'ipaddr' was high on the list of modules this
could be used for :)

Cheers,
Nick.

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