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).
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.
Seems like a good summary. I hope there will be a PEP from Steven for
the inclusion of argparse. It's all a bit of a moot debate because we
don't even need to decide whether to remove optparse now - we can start
it down the deprecation road and *possibly* remove it eventually...
Personally I would like to see dead modules removed (whilst some would
like to see the whole standard library dead ;-) - but our deprecation
process is deliberately slow so that issues like this can be deliberated
on a case by case basis over a period of years.
Michael
Paul.
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
