Brett Cannon wrote:
On Mon, Sep 14, 2009 at 10:06, Michael Foord <mich...@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
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
