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@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
