Perceived optparse shortcomings

Hans-Joachim Widmaier hjwidmaier at web.de
Wed Mar 17 08:20:10 CET 2004


I was really pleased when the Optik module found its way into the
standard Python battery compartment, as it matched all my option
parsing requirements. But, as always, there's really nothing that does
all you ever want, especially when it comes to option parsing -
there's just too many schemes to handle them all comfortably.

With this program I'm working on, I started to recognize that not only
the functionality should be delegated to modules, but that most
command line options are private to these modules (call 'em plug-ins)
as well. This calls for a command line like CVS or subverion employ:

<cmd> <generic options> <subcmd> <subcmd options> <args>

There are several ways to do it:
 - Let one option parser recognize all options. No drop-in plug-ins,
no possibility for the same options meaning different things in
different plug-ins (no, this isn't neccessarily a bad design anyway).
Obviously horrible.
 - 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. Even with modern shells its a nuisance to
have to go to the line's beginning, skip the command and insert the
option.
 - Augment optparse to just ignore unknown options and treat them as
arguments. Doesn't allow clustering of generic and subcommand-specific
options, doesn't allow for generic options to be arguments to
subcommand-specific options, 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).

The bigger problem, though, is internationalization. I don't care for
all the exceptions raised by programmer errors, but the usage, help
and user-visible error messages should really be inernationalized.
Subclassing optparse doesn't help much here, as the strings are
sprinkled all over. Is it even thinkable that optparse (or, in the
end, the whole standard library) be prepared for internationalization?
Couldn't it be handled like that:

At the module's top:

import __builtin__
try:
    __builtin__._
except AttributeError:
    def _(s):
        return s

and surrounding all relevant strings with _()?

Having all programs only talk english or having to rewrite every
module certainly can't be the answer.

Deutsch labernd der Eure,
Hans-Joachim Widmaier



More information about the Python-list mailing list