[stdlib-sig] Breaking out the stdlib

[Michael Foord]

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

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.

Michael

>
> _______________________________________________
> stdlib-sig mailing list
> stdlib-sig at python.org
> http://mail.python.org/mailman/listinfo/stdlib-sig
>   


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