On Jan 28, 2012, at 11:37 AM, Nick Coghlan wrote: >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."
Would it be acceptable then for a distro to disable __preview__ or empty it out? The thinking goes like this: if you would normally use an __preview__ module because you can't get approval to download some random package from PyPI, well then your distro probably could or should provide it, so get it from them. In fact, if the number of __preview__ modules is kept low, *and* PyPI equivalents were a requirement, then a distro vendor could just ensure those PyPI versions are available as distro packages outside of the __preview__ stdlib namespace (i.e. in their normal third-party namespace). Then folks developing on that platform could just use the distro package and ignore __preview__. If that's acceptable, then maybe it should be explicitly so in the PEP. -Barry
signature.asc
Description: PGP signature
_______________________________________________ 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
