On 28 January 2012 01:48, Barry Warsaw <barry@python.org> wrote:
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__.
Just so that you know that such cases exist, I am in a position where I have access to systems with (distro-supplied) Python installed. I can use anything supplied with Python (i.e., the stdlib - and __preview__ would fall into this category as well). And yet I have essentially no means of gaining access to any 3rd party modules, whether they are packaged by the distro or obtained from PyPI. (And "build your own" isn't an option in many cases, if only because a C compiler may well not be available!) This is essentially due to corporate inertia and bogged down "do-nothing" policies rather than due dilligence or supportability concerns. But it is a reality for me (and many others, I suspect). Having said this, of course, the same corporate inertia means that Python 3.3 is a pipe-dream for me in those environments for many years yet. So ignoring them may be reasonable. Just some facts to consider :-) Paul.