I've been writing an optparse alternative (using getopt) that is at a stage where I'd be interested in people's opinions.
Some more detailed comments:
* 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.
* Any reason why you aren't using new-style classes?
* I think the code would be easier to navigate in a single module.
* Your code alternates between underscore_names and camelCaseNames. Might be better to stick with one or the other. (PEP 8 suggests the former.)
* 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):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.
Hope these comments are at least marginally useful. ;)
STeVe -- http://mail.python.org/mailman/listinfo/python-list
