[stdlib-sig] Breaking out the stdlib

[Brett Cannon]

On Mon, Sep 14, 2009 at 10:06, Michael Foord <michael at voidspace.org.uk> wrote:
> Antoine Pitrou wrote:
>>
>> Le lundi 14 septembre 2009 à 12:19 -0400, Jesse Noller a écrit :
>>
>>>
>>> Sure, having batteries is fantastic. Until you being to realize that
>>> some modules are broken, not up to date with current technology, etc,
>>> etc. We have to be aggressive with cleaning it up.
>>>
>>
>> [...]
>>
>>>
>>> Things within the stdlib must have a high quality bar, and should
>>> really represent the "one way of doing something" - meaning best of
>>> breed, high quality, idiomatic, etc.
>>>
>>
>> Have you read the thread about argparse and the deprecation of other
>> modules?
>>
>> You are conflating two things:
>> 1. the presence of somewhat outdated or too low-level modules
>> 2. the desire to have best-of-breed options available in the stdlib
>>
>> We can do 2. without undoing 1. As Marc-André pointed out, even in py3k
>> we only deprecated a handful of very marginal modules. Emphasizing the
>> right modules in the documentation is probably a reasonably good answer
>> to the problem of having several modules fulfilling the same needs. No
>> need to go on a deprecation frenzy and start annoying the two thirds of
>> our user base just because we decided to be pure rather than practical.
>>
>>
>
> I think both 1) and 2) are on topic for a discussion of how we deal with
> standard library quality.
>
> No-one argues that the standard library should evolve quickly but there do
> seem to be those arguing that it should *never* evolve.
>
> I agree with Jesse (FWIW) that the presence of obsolete modules is actually
> damaging to Python.

Both in reputation and in developer time. It doesn't help our image
when someone finds a module in our standard library that is
practically unmaintained and goes w/o having patches applied. I think
this is Jesse's motivation behind wanting owners of modules; since the
core devs are volunteers we only patch stuff we care about, which
leads to orphaned modules rotting in the stdlib. And tying into this,
having to patch and fix modules that are outdated and not widely used
is a waste of time when it could have been spent working on code that
is more impactful on the wider community.

> Deprecating and removing modules over a four or five
> years (PendingDeprecation -> Deprecation -> removal) is more than slow
> enough for a stable system that is the Python standard library.
>

Well, to get your four or five year warning you need to have three
releases (3 * 18 months = 4.5 years), so releases would have to go
PendingDeprecation -> Deprecation -> Deprecation -> removal.

> I would love to see a PEP about further standard library clean-ups, perhaps
> slating modules for *eventual* removal in Python 3.4 / 3.5 and only when
> they are clearly not useful, replaced or broken and not maintained - and
> preferably where there is a clear alternative.

You can go back and look at early drafts of PEP 3108 for ideas. To
simply keep myself from burning out and making sure something happened
I had to cut a lot out, but I bet there is stuff we can toss (I mean
do we really need to be supporting any multimedia formats like
sunau?). If there is enough support we can try to come up with
standard library inclusion guidelines (what we are striving for,
quality standards, etc.) and then apply those to the existing stdlib
to potentially clean it up.

-Brett