On Sat, Jan 28, 2012 at 8:54 AM, Barry Warsaw <ba...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
