Perceived optparse shortcomings

[Hans-Joachim Widmaier]

David Goodger <goodger at python.org> wrote in message news:<mailman.83.1079535848.742.python-list at python.org>...
> Hans-Joachim Widmaier wrote:
>  > This calls for a command line like CVS or subverion employ:
>  >
>  > <cmd> <generic options> <subcmd> <subcmd options> <args>
> 
> I suggest the following:
> 
> 1. Build an OptionParser for your <cmd> that accepts only the generic
>     options.  Make sure to call
>     OptionParser.disable_interspersed_args() before calling
>     .parse_args().  The first argument in the returned args list should
>     be your <subcmd> (be sure to check!).

As I wrote somewhat later: I dislike
OptionParser.disable_interspersed_args().
<subcmd> is in reality just another option (as it's not really a
command; it selects a plugin that handles the special requirements of
a device).

> 2. Once you know your <subcmd>, build a new OptionParser that handles
>     its options.  Pass the argument list returned from step 1 (less the
>     subcmd) to .parse_args().

I have a generic interface that handles the generic options, scans its
directory for plug-ins and imports them. If one is selected, the
not-consumed arguments (and options) are passed to it. The plug-in
then does standard option parsing.
Works like a charm. (Bigger picture: The whole thing has a GUI also,
where you can select the plug-in interactively; the whole commandline
thing is to allow for a batch mode, too.)

>     If you really want the subcmd's option parser to handle the <cmd>'s
>     generic options too, you could augment the OptionParser built in
>     step 1:

There's just one option that needs to be handled, too (so it can be
called itself). Trivial to just define it with SUPPRESS_HELP if not
called standalone.

>  >  - Augment optparse to just ignore unknown options and treat them as
>  > arguments.
>
> There goes all error-checking.

Nah, it doesn't. Of course this is optional, and after the plug-in
parses the remains, there's nothing left to worry about.
 
>  > doesn't allow for generic options to be arguments to
>  > subcommand-specific options,
> 
> What does that mean?

E.g. if you have a generic option --bar and a subcmd-specific option
--foo that takes a string argument. Now if you call

<cmd> <subcmd> --foo --bar

--bar will be seen as a generic option and not as an argument to
--foo. But that's not really a problem, as it _is_ ambigous anyway
(might be a forgotten argument after all).

> Your "minor points" will be major to someone else, so I doubt a
> simplistic patch will be accepted.  But by all means, show the code
> (not here though; see below).

The patch is just a few lines (and took much less time to write than
this article), and it only implements an optional argument to
OptionParser.parse_args() that allows it to treat unknown options as
arguments.

> In any case, discussions here are unlikely to be seen, and almost
> certainly won't be acted upon.  I suggest posting to the optik-users
> (@lists.sf.net) list or filing a feature request.  A working code,
> test, & doc patch would be helpful too.

Thanks for your suggestion.
Hans-Joachim