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). I think the issue with argparse vs optparse is that argparse appears to be intended as "optparse done right" (I can't comment on whether it is, just that's what it looks like). So having both in the stdlib looks like duplication (far more so than having getopt along with either). If optparse was still evolving, it should be possible to devise some way of merging the two (possibly with API breakages, admittedly). The dilemma here seems to be that optparse won't change, and argparse offers extra functionality that people actually want (and would like in the stdlib). Something needs to give. Paul. _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
