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

[Nick Coghlan]

On Sat, Jan 28, 2012 at 8:54 AM, Barry Warsaw <barry at python.org> wrote:
> I think the OS vendor problem is easier with an application that uses some
> PyPI package, because I can always make that package available to the
> application by pulling in the version I care about.  It's harder if a newer,
> incompatible version is released upstream and I want to provide both, but I
> don't think __preview__ addresses that.  A robust, standard approach to
> versioning of modules would though, and I think would better solve what
> __preview__ is trying to solve.

I'd be A-OK with an explicit requirement that *any* module shipped in
__preview__ must have a third-party supported multi-version compatible
alternative on PyPI. (PEP 2 actually pretty much says that should be
the case, but making it mandatory in the __preview__ case would be a
good idea).

As an OS vendor, you'd then be able to say: "Don't use __preview__,
since that will cause problems when we next upgrade the system Python.
Use the PyPI version instead."

Then the stdlib docs for that module (while it is in __preview__)
would say "If you are able to easily use third party packages, package
<X> offers this API for multiple Python versions with stronger API
stability guarantees. This preview version of the module is for use in
environments that specifically target a single Python version and/or
where the use of third party packages outside the standard library
poses additional complications beyond simply downloading and
installing the code."

Cheers,
Nick.

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