optparse alternative

[Henry Ludemann]

I've been writing an optparse alternative (using getopt) that is at a
stage where I'd be interested in people's opinions. It allows you to
easily creating command line interfaces to existing functions, using
flags (which are optional) and arguments. It will automatically print a
nicely formatted usage (eg: -h or --help), and easily & automatically
validates parameter existence and type.

You can download it, and read a bit more about it, at


I'm interested in comments and criticisms; I've tried to write it
according to the python coding guildlines.

Example usage of a cmdline usage;

$ python test.py --help
Usage: test.py [OPTIONS] SOMEARG
An example to show usage of command line

Arguments
SOMEARG   Some float argument

Mandatory arguments to long flags are mandatory for short options
too
-h, --helpShow this help page
-s, --setflag Set the flag

Email bug reports to [EMAIL PROTECTED]

Source for the above example;

def someFunc(someArg, someFlag = False):
print "Flag value =", someFlag
print "Arg value =", someArg

from cmdline.Command import Command
command = Command(someFunc, "An example to show usage of command
line", "Email bug reports to [EMAIL PROTECTED]")
command.addFlag('s', 'setflag', 'Set the flag', 'someFlag')
command.addArgument('SOMEARG', 'Some float argument', 'someArg',
float)
command.invoke()

Normal use of test.py would have given

$ python test.py 3
Flag value =  False
Arg value = 3.0

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: optparse alternative

[Henry Ludemann]

Thanks for the comments...
Steven Bethard wrote:
Looks interesting, but is it really that different from optparse?
In the sense that they both do the same thing, no, not really. But the
way they do it is quite different; optparse bases itself on setting
variables, while this module is for invoking functions. I like this way
a better, as it acts as a more 'usual' client of the code, in the sense
that it uses publically exposed interfaces rather then internal
variables for passing the information. That said, the reason I started
this was that at the time I wasn't aware of optparse; my search through
the help needed to be a bit more thorough. When I found optparse, I
decided to continue on with this approach (mostly because I was having
fun with it).
I do like the fact that you can specify a type with a conversion 
function.  (In optparse, AFAIK, to add a new type you have to write 
your own subclass of Option that screws with Option.TYPES and 
Option.TYPE_CHECKER, which I've always thought was kinda nasty.)
Yeah, it works quite nicely; as it is a general function, you can use
your own methods for creating arbitrary objects (so long as they take
one parameter (a string)).
But I wonder if it wouldn't be better to extend optparse with the 
functionality instead of writing an entirely new module...
The way of getting the data through to the program is quite different
(method vs data), so that would be a fairly radical change / addition
for optparse.
--
http://mail.python.org/mailman/listinfo/python-list

Re: optparse alternative

[Henry Ludemann]

* The more I think about it, the more I like that you're basically 
constructing options to match a function signature.  But I can imagine 
that this might be too restrictive for some uses.  It might be worth 
having an alternate interface that provides an options object like 
optparse does.

It is matching options to a function signiture, and for complex methods, 
this might be too restrictive (for example, you'd get methods with 10 - 
20 params). That said, many cases don't have this many things that can 
be set.

Although your point about providing an alternate interface is a good one...
* Any reason why you aren't using new-style classes?

Ignorance. I'll look into it...
* I think the code would be easier to navigate in a single module.

It might be easier to navigate (eg: when you want to go to a method 
implmentation), but from a maintenance point of view I feel modular code 
is easier... Mostly this is instint from other languages (mostly c++).

* Your code alternates between underscore_names and camelCaseNames. 
Might be better to stick with one or the other.  (PEP 8 suggests the 
former.)

Yeah, I coded it before I looked at PEP8. Initially it was all camel 
case, and I attempted to retrofit it. It seems like classes should still 
be CamelCase, yes?

* File specific comments:
Argument.py:
Drop the get_name method; name attribute is already accessible.  (The 
property builtin makes getters and setters generally unnecessary.)

CommandArgument.py:
Drop the get_param_name method; param_name attribute is already 
accessible

Flag.py:
__init__ should have defaults where applicable (e.g. the comments say 
you can provide None for short_flag, but it doesn't default to this). 
Should also probably produce an error if neither short_flag nor 
long_flag is set.  (Or do this in Command._add_options)

In get_value, use "self.argument is None" not "self.argument == None".
get_flag_name should default to long_flag, not short_flag
Command.py:
add_flag should call _validate_param_name *before* _add_options (in 
case an exception is raised and caught).

In _get_params,
for arg_index in range(len(method_args)):
arg = method_args[arg_index]
could be replaced with
for arg_index, arg in enumerate(method_args):

Will do...
MulipleLines.py:
Can you use the (standard library) textwrap module instead?  Seems 
like they do about the same thing, but I haven't looked in too much 
detail.

Doh! Yep, they do the same thing. This is another case of my not 
checking the standard library well enough.

Hope these comments are at least marginally useful. ;)

Yes, very useful. Thanks very much for spending the time to go over it...
--
http://mail.python.org/mailman/listinfo/python-list

Re: optparse alternative

[Henry Ludemann]

As far as I can tell, your module has one functional advantage over
optparse--it validates arguments as well as options.
Functionality wise, that is probably about it. It is more from a 
seperation of command line / functionality code that I wrote this; that 
the command line code should be seperate from the actual functional code.

The rest seems to be cosmetics, and personally I prefer the cosmetics 
of optparse.
All to their own... I actually wrote this before I was aware of 
optparse, and so didn't consider the benefits / disadvantages of that 
way of doing it. It's simply a different approach. That said, what I 
like about this approach is that it is non-obtrusive on the functional code.

For one thing, it uses the variable/function naming style found 
throughout
most of the stdlib. 
True... I originally wrote the code in camel case, and have attempted to 
change it to the standard from PEP 8. I guess I missed a few things :-)

optparse has also been widely used and tested for
the last four years.
Again, true, but then again, this module (unlike optparse) uses the 
standard getopt module for all command line parsing, which has been 
around for even longer. So the bugs are all in the method invoking (my 
code), and not in the parsing. 

I think you would be better off trying to extend optparse to deal with
non-option arguments, and you can tap into the installed base of
existing optparse users and even get your code included in the stdlib
if Greg Ward agrees. Whereas that's really unlikely for an entirely
new module--there just isn't the need for a THIRD way to do the same
thing.
Yeah, a third module would be a bit redundent. I had actually written 
most of this module before I became aware of optparse (it was one of 
those bash the head against the wall moments when I found it), but 
decided to continue with this version because I liked the cosmetics of 
it (it seemed less intrusive on the functional code). Once it was more 
or less finished, I decided to clean it up and post it in the hope it 
might be useful to someone else, and perhaps more, to get any comments 
that could improve it. And besides, variety is the spice of life :-)

Just a suggestion.
Thanks for your comments...
--
http://mail.python.org/mailman/listinfo/python-list