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

Michael Foord fuzzyman at voidspace.org.uk
Sat Jan 28 17:05:11 CET 2012

On 28/01/2012 05:09, Scott Dial wrote:
> On 1/27/2012 8:48 PM, Barry Warsaw 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.
> That is my thought about the entire __preview__ concept. Anything that
> would/should go into __preview__ would be better off being packaged for
> a couple of key distros (e.g., Ubuntu/Fedora/Gentoo) where they would
> get better visibility than just being on PyPI and would be more flexible
> in terms of release schedule to allow API changes.
> If the effort being put into making the __preview__ package was put into
> packaging those modules for distros,

That effort wouldn't be put in though. Largely those involved in working 
on Python are not the ones packaging for Linux distributions. So it 
isn't an alternative to __preview__ - it could happily be done alongside 
it though. Those who work on Python won't just switch to Linux if this 
proposal isn't accepted, they'll do different work on Python instead.

>   then you would get the same
> exposure
Packaging libraries for Linux gets you no exposure on Windows or the 
Mac, so __preview__ is wider.

>   with better flexibility and a better maintenance story.  The
> whole idea of __preview__ seems to be a workaround for the difficult
> packaging story for Python modules on common distros
I don't know where you got that impression. :-)

One of the reasons for __preview__ is that it means integrating 
libraries with the Python build and test systems, for all platforms. 
Packaging for [some-variants-of] Linux only doesn't do anything for this.

All the best,


> -- stuffing them
> into __preview__ is a cheat to get the distro packagers to distribute
> these interesting modules since we would be bundling them.
> However, as you have pointed out, it would very desirable to them to not
> do so. So in the end, these modules may not receive as wide of
> visibility as the PEP suggests. I could very easily imagine the more
> stable distributions refusing or patching anything that used __preview__
> in order to eliminate difficulties.


May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

More information about the Python-Dev mailing list