[Python-Dev] External Package Maintenance (was Re: Please stopchanging wsgiref on the trunk)

Giovanni Bajo rasky at develer.com
Mon Jun 12 20:20:10 CEST 2006

Guido van Rossum wrote:

>>> I personally think that, going forward, external maintainers should
>>> not be granted privileges such as are being granted by PEP 360, and
>>> an inclusion of a package in the Python tree should be considered a
>>> "fork" for all practical purposes. If an external developer is not
>>> okay with such an arrangement, they shouldn't contribute.
>> This is going to make it tougher to get good contributions, where
>> "good" means "has existing users and a maintainer committed to
>> supporting them".
> To which I say, "fine". From the Python core maintainers' POV, more
> standard library code is just more of a maintenance burden. Maybe we
> should get serious about slimming down the core distribution and
> having a separate group of people maintain sumo bundles containing
> Python and lots of other stuff.


One of the biggest Python strength, and one that I personally rely on a lot,
is the large *standard* library. It means that you can write scripts and
programs that will run on any Python installation out there, no matter how
many eggs were downloaded before, no matter whether the Internet connection
is available or not, no matter if the user has privileges to install
extensions, even if the SourceForge mirror is down, even if SourceForge
changed their HTML and now the magic code can't grok it anymore, etc etc

If Python were to lose this standard library in favor of several different
distributions, users could not sensibly write a program anymore without
incurring the risk of using packages not available to some users. Perl has
this problem with CPAN, and system administrators going through hoops to
write admin scripts which do not rely on any external package just because
you can't be sure if a package is installed or not; this leads to code
duplication (duplication of the code included in an external package, but
which can't be "reliably" used), and to bugs (since the local copy of the
functionality can surely be more buggy than the widespread implementation of
the external package).

Let's not get into this mess, please. I think we just need a smoother way to
maintain the standard library, not an agreement to remove it, just because
we cannot find a way to maintain it properly. The fact that there hundreds
of unreviewed patches to the standard library made by wannabe contributors
is a blatant sign that something *can* be improved.
Giovanni Bajo

More information about the Python-Dev mailing list