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

[Stephen J. Turnbull]

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.