Antoine Pitrou schrieb: > Le mardi 15 septembre 2009 à 21:51 +0200, Georg Brandl a écrit : >> >> Of course it does them reasonably well. But for most of these "common" >> use cases you talk about above, a replacement library will be able to >> offer the same or a very similar API, so the breakage is not much worse >> than with md5/hashlib. > > Well I do think that md5 shouldn't have been deprecated in 2.x. AFAIU, > it was easy to continue supporting it (by creating a simple stub); > annoying users wasn't worth what we gained in maintenance, IMO. > > But regardless, this is not the same situation. Migrating from md5 to > hashlib is simply changing an import line and a module name. Migrating > from optparse to argparse involves an API change.
Maybe. (I don't know argparse.) But I can imagine that providing a simple compatibility API that supports creating OptionParsers and calling add_option() and parse() on them would be easy if not trivial, and that's what most users of optparse use. >> I wouldn't say it has few bugs filed against it; sadly I have no hard data, >> but since I read each new tracker item (or at least the title), I would say >> that there are many modules that have fewer bugs filed than optparse. >> >> Of course, this also is correlated with the module's size (it's currently >> the 12th largest single module in trunk/Lib). > > It is also correlated with the module's usefulness. Parsing command line > options is certainly much more common than, say, normalizing unicode > strings or adding fractions together. This is true, but it doesn't make the bugs less or less important, but potentially even more important. Endly, that results either in more work or in dissatisfied users. cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig