Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #49346 > unrolled thread

Re: Why is the argparse module so inflexible?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Why is the argparse module so inflexible? Jason Swails <jason.swails@gmail.com> - 2013-06-27 17:30 -0400
    Re: Why is the argparse module so inflexible? Grant Edwards <invalid@invalid.invalid> - 2013-06-27 22:19 +0000
      Re: Why is the argparse module so inflexible? Chris Angelico <rosuav@gmail.com> - 2013-06-28 08:33 +1000

#49346 — Re: Why is the argparse module so inflexible?

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jun 27, 2013 at 2:50 PM, Ethan Furman <ethan@stoneleaf.us> wrote:

>
> If the OP is writing an interactive shell, shouldn't `cmd` be used instead
> of `argparse`?  argparse is, after all, intended for argument parsing of
> command line scripts, not for interactive work.
>

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.

Let's say that one of the user's commands requires an integer but they give
a float or a string by accident: I believe the OP wants ArgumentParser to
pass the appropriate ArgumentError exception up to the calling routine
rather than catching it and calling ArgumentParser.error(), thereby
destroying information about the exception type and instead requiring him
to rely on parsing the far less reliable error message (since it's
reasonable to expect that kind of thing to change from version to version).
 This way his calling routine can indicate to the user what was wrong with
the last command and soldier on without bailing out of the program (or
doing something ugly like catching a SystemExit and parsing argparse's
error message).

As it stands now, ArgumentParser has only limited utility in this respect
since all parsing errors result in a SystemExit exception being thrown.
 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).  While argparse was not specifically
designed for what the OP is trying to do, it would satisfy his needs nicely
except for the previously mentioned issue.

An alternative is, of course, to simply subclass ArgumentParser and copy
over all of the code that catches an ArgumentError to eliminate the
internal exception handling and instead allow them to propagate the call
stack.

All the best,
Jason

[toc] | [next] | [standalone]

#49347

On 2013-06-27, Jason Swails <jason.swails@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.  ;)

-- 
Grant Edwards               grant.b.edwards        Yow! ... I want to perform
                                  at               cranial activities with
                              gmail.com            Tuesday Weld!!

[toc] | [prev] | [next] | [standalone]

#49348

On Fri, Jun 28, 2013 at 8:19 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2013-06-27, Jason Swails <jason.swails@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@bar:~$ progname subcommand blah blah
foo@bar:~$ progname subcommand blah blah
foo@bar:~$ progname subcommand blah blah

and

foo@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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web