Perceived optparse shortcomings

[David Goodger]

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!).

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().

    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:

        parser = OptionParser()
        parser.add_option(...)
        ...
        parser.disable_interspersed_args()
        values, args = parser.parse_args()

        subcmd = args[0]
        parser.add_option(...)  # depending on subcmd
        ...
        parser.enable_interspersed_args()  # if you like
        values, args = parser.parse_args(args=args[1:], values=values)

    You'll have to be careful about conflicts.

 >  - Don't allow interspersed arguments. This is something I
 > dislike. I want to be able to type a forgotten generic option when
 > I'm at the end of a possibly long line.

You won't have any arguments *before* the subcmd, so the above should
work for you.

 >  - Augment optparse to just ignore unknown options and treat them as
 > arguments.

There goes all error-checking.

 > Doesn't allow clustering of generic and subcommand-specific options,

You'd have to avoid conflicts completely.

 > doesn't allow for generic options to be arguments to
 > subcommand-specific options,

What does that mean?

 > but these seem as minor points to me. So I did that. And I'd like to
 > ask if this might have a chance to get into the standard optparse
 > module (It's just a few lines).

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 bigger problem, though, is internationalization. ... Is it even
 > thinkable that optparse (or, in the end, the whole standard library)
 > be prepared for internationalization?

I imagine that optparse would be open to internationalization.  I'd
like to see some of optparse's strings be parameterized instead of
hard-coded.  These changes just need someone to implement (and write
tests for, and document) them.

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.

-- 
David Goodger                               http://python.net/~goodger
For hire: http://python.net/~goodger/cv