[stdlib-sig] Breaking out the stdlib

[Antoine Pitrou]

Le mardi 15 septembre 2009 à 14:38 +0000, Collin Winter a écrit :
> This is no
> different than upgrading versions of Postgres, gcc or Linux: it has
> risks, but gcc doesn't upgrade itself on its own.

But there *is* a difference between unforeseen bugs (which are an
unavoidable pitfall of software development), and deliberate removal of
widely used features.

Your reasoning is like saying: there will be unforeseen bugs anyway, so
we can just create deliberate bugs for the sake of it.

> Frankly, this sounds like an *excellent* reason to get rid of optparse
> and replace it with something more flexible.

It *would* have been an excellent reason to choose argparse over
optparse in the first place. But since optparse is already in the
stdlib, we have users to care about.

> This is a problem for
> users of that package, who may wish to use newer version of Python for
> performance or bug-fix reasons,

This is a reason for keeping that package in the stdlib, not for
removing it.

> and it is also a problem for
> python-dev, since those frozen packages create inertia.

I'm not sure what inertia you're talking about. The presence of the
Lib/optparse.py file does not look like a deterrent to contributing to
any other part of the interpreter or the stdlib. Lib/optparse.py itself
doesn't seem to receive a lot of checkins, and most are cosmetic. There
are very few open bugs concerning optparse in bugs.python.org, and most
seem normal/low priority. From this I gather that:
1) optparse is low maintenance (requires few checkins)
2) optparse is low annoyance (doesn't clutter the bug tracker)

Taking optparse as an example defeats your point more than it helps it,
IMO. You should choose a bug-ridden module with an awful API, not
something perfectly decent which fits lots of everyday use cases.