[Python-Dev] Pronouncement on PEP 389: argparse?
steven.bethard at gmail.com
Mon Dec 14 19:43:14 CET 2009
On Mon, Dec 14, 2009 at 10:22 AM, Ian Bicking <ianb at colorstudy.com> wrote:
> On Mon, Dec 14, 2009 at 12:04 PM, Steven Bethard
> <steven.bethard at gmail.com> wrote:
>> So there wasn't really any more feedback on the last post of the
>> argparse PEP other than a typo fix and another +1.
> I just converted a script over to argparse. It seems nice enough, I
> was doing a two-level command, and it was quite handy for that.
> One concern I had is that the naming seems at times trivially
> different than optparse, just because "opt" or "option" is replaced by
> "arg" or "argument". So .add_option becomes .add_argument, and
> OptionParser becomes ArgumentParser. This seems unnecessary to me,
> and it make converting the application harder than it had to be. It
> wasn't hard, but it could have been really easy. There are a couple
> other details like this that I think are worth resolving if argparse
> really is supposed to replace optparse.
Thanks for the feedback. Could you comment further on exactly what
would be sufficient? It would be easy, for example, to add a subclass
of ArgumentParser called OptionParser that has an add_option method.
Do you also need the following things to work?
* options, args = parser.parse_args() # options and args aren't
separate in argparse
* type='int', etc. # string type names aren't used in argparse
* action='store_false' default value is None # it's True in argparse
These latter kind of changes seem sketchier to me - they would make
the initial conversion easier, but would make using argparse normally
> I'd change this language:
> "The optparse module is deprecated, and has been replaced by the
> argparse module."
> "The optparse module is deprecated and will not be developed further;
> development will continue with the argparse module"
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
More information about the Python-Dev