[stdlib-sig] Breaking out the stdlib

[Michael Foord]

Brett Cannon wrote:
> 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.
>
>   

I totally agree. It wastes our time and it wastes the time of users who 
attempt to use these modules and get frustrated with Python as a result.

>> 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.
>
>   

That sounds fine to me.

>> 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
>   
Yep, sounds like a good way forward for Jesse. He has my full support. ;-)

Michael

-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog