Paul Moore wrote: > 2009/9/15 Michael Foord <mich...@voidspace.org.uk>: >> Right - but part of the specific problem with optparse is that in many >> situations it does a very inadequate job (i.e. it "it does what it is meant >> to do" but not what many people "need it to do") and is designed in such a >> way that *required* functionality can't be added in a backwards compatible >> way. >> >> That is not "good code" (by my reckoning). > > As such, optparse needs to change (assuming that the stdlib *should* > be "good code"). There are requirements (feature requests at least, > possibly even bugs) which need addressing. > > If no maintainer can be found to do this, then optparse is de facto > dead and unmaintained.(Laura's B-2). No-one has made a statement about > what should be done with B-2 code in the stdlib, but I can see good > arguments for allowing the possibility of dropping it in favour of a > replacement library. > > If someone wants to argue that optparse is class "C" (ie, it is > "finished" and "complete") then that's a different matter. Requests > for optparse to support required arguments, or to better support user > extension, would then be closed "won't fix - this is by design". And > in that case, it *is* more or less by definition "good code" - it > fulfills its aims, it just doesn't aim to do what Michael states many > people "need it to do" above. (Personally, I don't see that code can > be described as "good" if it doesn't aim to do what people need, but > maybe someone wants to argue this).
Please note that adding functionality to such class "C" module is still allowed - provided it doesn't break anything. This has been done with optparse and getopt a few times already and is common practice with other such modules as well. In Laura's particular case, there does appear to be an easy solution which adds just that one feature: http://code.activestate.com/recipes/573441/ Things do get problematic if you want to approach a problem from a whole new angle, e.g. say you want to have XML DOM parsing instead of SAX parsing. In such a case, adding a whole new module would be better. Even though you're still parsing XML in both cases, the new module would provide a new method to do so. Much like the urllib2 provides a new and different way to handle URL fetching compared to urllib. There's also a third case: If a module cannot be updated or extended to support a major new feature mandated by the Python language, such as Unicode support, then there is little choice other than to replace it with a new module. This has happened with the pcre module that used to drive the re module - there was no way to get Unicode into pcre. The change was not really noticeable to the users, though, since the new module implemented the same API (and extended it). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 15 2009) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
