[stdlib-sig] Breaking out the stdlib
Laura Creighton
lac at openend.se
Tue Sep 15 21:10:58 CEST 2009
In a message of Tue, 15 Sep 2009 19:41:25 BST, Paul Moore writes:
>MAL pointed out http://code.activestate.com/recipes/573441/ - extended
>optparse to allow definition of required options. Given that one of
>the requirements that argparse is claimed to meet where optparse
>doesn't is supporting required arguments, how come this simple recipe
>hasn't been incorporated into optparse?
>
>The optparse/argparse case seems to rest on the argument that optparse
>cannot be extended to do what argparse does. It seems like this isn't
>true for all requirements. (And maybe some others could be addressed
>by judiciously deprecating support for specific internal details that
>maybe should not have been documented in the first place...)
Maybe, but this simple recipe only works for options which are
unconditionally required. What I needed was a solution for options
that are conditionally required -- if you have option X then you
must have option Q.
But optparse is particularly unhappy about this, and about other
things. If you type command --verbose --brief, and these are
toggles, then you will get the last one processed, brief in this
case. There is no easy way to say 'now please roll over and die'
because you have an incompatible set of options. I wrote code
that changed optparse to do what I wanted, but boy, was it ugly.
I can maybe dig it up somewhere. And when I went knocking, asking
optparse's author about how he would recommend that I solve my
problem using optparse in a way that was less ugly, I was told
that my problem wasn't to be solved using optparse.
So I would surmise that the reason this recipe isn't in the standard
library is optparse's author didn't want it in optparse.
>
>Paul.
>_______________________________________________
>stdlib-sig mailing list
>stdlib-sig at python.org
>http://mail.python.org/mailman/listinfo/stdlib-sig
More information about the stdlib-sig
mailing list