Why is the argparse module so inflexible?

Chris Angelico rosuav at gmail.com
Thu Jun 27 18:33:27 EDT 2013


On Fri, Jun 28, 2013 at 8:19 AM, Grant Edwards <invalid at invalid.invalid> wrote:
> On 2013-06-27, Jason Swails <jason.swails at gmail.com> wrote:
>
>> He _is_ using cmd.  He's subclassed cmd.Cmd and trying to use
>> argparse to handle argument parsing in the Cmd.precmd method to
>> preprocess the user input.
>
> [...]
>
>> Having subclassed cmd.Cmd myself in one of my programs and written my
>> own argument parsing class to service it, I can appreciate what the
>> OP is trying to do (and it's clever IMO).
>
> Unfortunately, when writing software, being "clever" turns out to be A
> Bad Thing(tm) as often as not.  ;)

I don't see that it needs to be, in this case. Fundamentally, what's
the difference between:

foo at bar:~$ progname subcommand blah blah
foo at bar:~$ progname subcommand blah blah
foo at bar:~$ progname subcommand blah blah

and

foo at bar:~$ progname
progname> subcommand blah blah
progname> subcommand blah blah
progname> subcommand blah blah
progname> ^D

? Seems to me your subcommands should be allowed to use argparse.

Yes, it's somewhat less usual usage. But it isn't inconceivable.

Why raise an exception, then catch it and raise SystemExit? Surely
*that* is the unusual behaviour - why not just let an ArgumentError
propagate up?

But with the module doing what it does, I'd say catching SystemExit is
the right thing to do. Deserves a code comment, but perfectly right.

ChrisA



More information about the Python-list mailing list