[getopt-sig] some comments about Optick

[Greg Ward]

On 13 February 2002, s. keim said:
> After a first dive into Optick documentation, I think that it seems very 
> promising.
> 
> I have some questions/suggestions about the API:

I'm not sure if this discussion belongs here or on the optik-users list.
This list should be for comparing/contrasting the various getopt
replacements/enhancements.  Oh well, here I go.


>  * I don't see the need for the level of indirection in the add_option 
> command.
> Wouldn't it be easier for the user to directly use functions objects:
> for sample:
> parser.add_option("-f", "--file", type=string, dest="filename",
>                         help="read data from FILENAME")

That presupposes that you have imported the name 'string' from
somewhere; since this conflicts with a standard library module, I'm not
too keen on it.

Or did you mean to put a type object there, like StringType or 'str'
(same thing in Python 2.2)?  Two problems with that:

  * tricky to make it work the same way < 2.2 and >= 2.2:
    if you want either 'str' or StringType to work in all versions
    of Python (seems desirable to me), then you have a work a
    little bit harder

  * what about extensibility?  one of the major features of Optik's
    type system is that its extensible: you could add a "file" or 
    "dir" or "outfile" type; some of those things correspond to
    Python types or builtins, and some don't

> or
> parser.add_option("-v", "--verbose",  action=parser.store_true,  
> dest="verbose")

...and that presupposes a name 'store_true' in each OptionParser
instance, which means that adding an action requires subclassing both
Option and OptionParser.

Using strings to represent types and actions might be slightly more
verbose, but I think it makes it easier to extend Optik: all you need to
do is recognize one more string.

> * It would be better to define call-back as functions with one arg. This 
> will allow you to change/extend the API only by appending attributes to 
> the argument and then without breaking existing call-back functions.

I took the opposite approach: go ahead and pass everything that might
someday be useful to some callbacks, so I don't have to extend the API
in future.  ;-) (Famous last words...)

> * Parsing value policy
> in the doc:
> >Let's parse another fake command-line.  This time, we'll jam the option
> >argument right up against the option -- "-n42" (one argument) is
> >equivalent to "-n 42" (two arguments).
> in the second case, how the parser know that 42 is the value of the -n 
> argument and not  a positional parameter? Is it because we have defined 
> that action="store"?

No, it's because this option has a type and therefore takes a value.
(action="store" without a type is (currently) an error; I'm thinking of
making the default type "string" because that's the usual case.)

> * This is mainly a matter of taste, but I'd like to have the dest 
> argument optional, if the long option is defined:
> parser.add_option("-v", "--verbose",  action="store_true")
> would be equivalent to:
> parser.add_option("-v", "--verbose",  action="store_true",  
> dest="verbose")

Ooh, good idea!  Filed in my mental to-do list.

> * required parameters
> I haven't see this in documentation, so I suggest to add a field to 
> options:
> Option("-f", action="store", type="string", dest="filename", required=1)
> Then parser will fail if the -f option doesn't exist in the command line

The phrase "required option" is an oxymoron.  Think about it.  (Also,
look in the optik-users archive -- this was discussed a month or so
ago.)

(But if enough users want the damn feature, I'll probably add it.  I'm
like that.)

> *groups
> Sometime, you want to manage options by groups:
> - the user can only supply one of the options of the group.
> - the user must supply at least one option of the group.
> I don't know how to express this yet, but this would be something 
> interesting to have. In fact this is probably quite related to the 
> "store_const" action.

No.  Optik knows anything about inter-option dependencies, nor should
it.  You can write your own code to do that after parser.parse_args()
returns.

> * default values
> I think that the command line parser shouldn't manage default values 
> because quite often software provide several way to define options:

So don't use that feature.  Quite often software takes options from the
command-line and nowhere else, and then having default values is really
handy.

> By the way, many informations are shared between the xxxx arguments of 
> the several parsers, so maybe we could look for an api that would 
> permit  to avoid duplication.

That's kind of the point of this sig: get something better than getopt
in the standard library, that everyone can live with.

        Greg
-- 
Greg Ward - Unix nerd                                   gward@python.net
http://starship.python.net/~gward/
Don't hate yourself in the morning -- sleep till noon.