Why is the argparse module so inflexible?

[Jason Swails]

On Thu, Jun 27, 2013 at 8:22 PM, Tim Chase <python.list at tim.thechases.com>wrote:

> On 2013-06-28 09:02, Cameron Simpson wrote:
> > On 27Jun2013 11:50, Ethan Furman <ethan at 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.
> >
> > I invoke command line scripts interactively. There's no special
> > case here.
> >
> > To add to the use case stats, I also subclass cmd and parse
> > interactive command lines. I'm beginning to be pleased I'm still
> > using Getopt for that instead of feeling I'm lagging behind the
> > times.
>
> I too have several small utilities that use a combination of cmd.Cmd,
> shlex.shlex(), and command-processing libraries.  However, much like
> Cameron's code using getopt, my older code is still using optparse
> which gives me the ability to override the error() method's default
> sys.exit() behavior and instead raise the exception of your choice.
>

There's nothing in argparse preventing this.  There's still an
ArgumentParser.error() method that you can override to raise an exception.
 The problem is that the original exception ArgumentParser raised when it
hit a parsing error was lost as soon as the parsing routine caught said
exception.

Therefore, your new error() method must parse the message being passed to
it in order to determine what error occurred and raise the corresponding
exception of your choice, or simply settle with telling the user there was
a generic argument parsing error that they have to figure out.

Being a prolific user of argparse myself (I use it or optparse in nearly
every script I write, although I greatly prefer argparse), I recognize it
as an incredibly feature-packed, convenient, easy-to-use library.  It's too
bad that the utility of this library for non-commandline argument parsing
is limited by a seemingly unnecessary feature.

Of course, in RRsPy4k this whole module will just be replaced with "raise
PyWart('All interfaces must be graphical')" and this whole thread will be
moot. :)

All the best,
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20130627/69e58ae2/attachment.html>