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. _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
