[Python-Dev] PEP 408 -- Standard library preview package (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sat Jan 28 02:27:35 CET 2012

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:

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

More information about the Python-Dev mailing list