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

Stephen J. Turnbull stephen at xemacs.org
Sat Jan 28 06:22:54 CET 2012

Executive summary:

If the promise to remove the module from preview is credible (ie, strictly kept), then preview will have a specific audience in those who want the stdlib candidate code and are willing to deal with a certain amount of instability in that code.

(Whether that audience is big enough to be worth the effort of managing preview is another question.)

Barry Warsaw writes:

I agree with everything Alex said here.

I don't necessarily disagree. But:

I can't argue with that, it's just that I don't think preview solves [the visibility] problem.

I do disagree with that. I frequently refer to the library reference for modules that do what I need, but almost never to PyPI (my own needs are usually not very hard to program, but if there's a stdlib module it's almost surely far more general, robust, and tested than my special-case code would be; PyPI provides far less of a robustness guarantee than a stdlib candidate would).

I don't know how big or important a use case this is, though I think that Antoine's point that a similar argument applies to those who develop software for their own internal use (like me, but they have actual standards for QA) is valid.

I think we'll just see folks using the unstable APIs and then complaining when we remove them, even though they know upfront that these APIs will go away.

So maybe the Hon. Mr. Broytman would be willing to supply a form letter for those folks, too. "We promised to remove the module from preview, and we did. We warned you the API would be likely unstable, and it was. You have no complaint." would be the gist.

A robust, standard approach to versioning of modules would though, and I think would better solve what preview is trying to solve.

I suspect that "robust, standard approach to versioning of modules" is an oxymoron. The semantics of "module version" from the point of view of application developers and users is very complex, and cannot be encapsulated in a linear sequence. The only reliable comparison that can be done on versions is equality (and Python knows that; that's why there is a stdlib bound to the core in the first place!)

I'm not so sure about that. If I were to actively try it, I'm not sure how much motivation I'd have to rewrite key parts of my code when an incompatible version gets promoted to the un__preview__d stdlib.

So use the old version of Python. You do that anyway. Or avoid APIs where you are unwilling to deal with more or less frequent changes. You do that anyway. And if you're motivated enough, use preview.

I don't understand what you think you lose here.

More information about the Python-Dev mailing list