Re: Positional arguments parsing

On 6/25/06, Diogo Kollross <[email protected]> wrote:
> > (Diogo: why do you require passing in a list in your examples? Why not
> > just use varargs instead?)
>
> Good question! I just didn't realize that I could have done that way. =]
>
> > I think it would make sense to reuse the type conversion and actions
> > that are already available for options in optparse.   (I assume
> > posparse does that.)
>
> Indeed, I tried to reuse as much from Optik as possible. IMHO, any
> interface to this feature should build on what is already possible
> with the standard parser.
>
> I wonder if it's better to have a simpler interface with only one
> positional arguments template or a more complex interface with the
> ability of parsing a number of different templates.

IMHO the current interface that Optik provides is nice enough.  The
arguments should implement some similar interface to what is already
there, something simple.


> Suggestion: the parser could be seen more like an arguments template
> than as a parser. We could define a template for the standard command
> line options and one template for each positional arguments
> alternative. Then we could combine the templates to do the parsing
> (warning: overloaded operators ahead!):
>
> options_template = Template()
> options_template.add_option("-v", dest = "verbose", action =
> "store_true", default = False)
>
> empty_template = Template()
>
> start_template = Template()
> start_template.add_argument("start", dest = "action", action =
> "store_const", const = "start")
> start_template.add_argument(dest = "filename")
> start_template.add_argument(dest = "priority", type = "int")
>
> stop_template = Template()
> stop_template.add_argument("stop", dest = "action", action =
> "store_const", const = "stop")
>
> all_templates = (options_template + empty_template) |
> (options_template + start_template) | (options_template +
> stop_template)
> options = all_templates.parse()
>
> Please let me know if something is exceedingly weird in the example... :p

I've implemented subcommands in a different way.  You can use multiple
optparse parsers to do that, by giving it an option to ignore unparsed
options, looking at the first positional argument, and then passing on
the rest of the arguments (and options) to another parser.   It looks
simpler than the template proposal you propose above (easier to
understand IMO).

However, there is a little bit of code involved;  it would actually be
super nice if Optik could include some code to support parsing
subcommands.  I never thought of submitting it.

The parser, in my view, is just a specification of the command-line
interface, rather than just a parser.  The "parser" bit is only part
of what makes it interesting.  I use it for generating documentation,
automatic completion for bash, and parsing the arguments.

BTW, have you seen optcomplete?  It also uses the parser as a
"template" of the arguments in order to automatically produce
completions for the bash shell:
http://furius.ca/optcomplete/
(I would be happy to hand over that code to be integrated into Optik
if anyone would like that.)

cheers,

Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642