Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #18861

Re: Introspecting optparse/argparse objects

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On 1/11/2012 19:37, alex23 wrote:
> On Jan 11, 11:26 am, Evan Driscoll <edrisc...@wisc.edu> wrote:
>> (For a concrete idea of a use case, suppose that it did not
>> directly support the --help option and I wanted to write code that took
>> its place.)
> That's a pretty weird definition of 'concrete use case', but anyway...
It's actually closer to the truth than it might seem. I want to feed a
bash-completion-style thing, using the same data structure to both
figure out the possible completions and also do the actual parsing. "Do
the actual parsing" = optparse/argparse, while "figure out the possible
completions" = I need to be able to look at a list.

> If you're wanting to extend the behaviour of the options, won't you
> need to wrap them anyway?
I don't have any need to extend the parsers other than to get the list
of options. (Though now that you've brought that up, perhaps looking at
the _private fields in a subclass would be the best tradeoff? Hmmm.)

> But more to the point, you already have the data: you used it to
> create the options. Why not just keep a handle on that data and refer
> to what you need directly?
But now you're talking about wrapping the parser, because there's no
builtin way (at least that I know of) to store the information in such a
way that you can call the function, because it uses a mix of positional
and keyword arguments. E.g. I can't say just
    args = ('-f', '--foo', help='do foo')
    ...
    parser.add_argument(*args)
but would have to say something like
    args = ( ('-f', '-foo'), {'help': 'do foo'})
    ...
    parser.add_argument(*args[0], *args[1])
or something like that.

I'd want to add some function like 'make_option' which wraps all that
up, and then provide a nicer interface for add_argument, etc., and it
seems like pretty soon I're reimplementing the optparse API. :-) Or at
least it might be that way.

Evan

Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Introspecting optparse/argparse objects Evan Driscoll <edriscoll@wisc.edu> - 2012-01-10 19:26 -0600
  Re: Introspecting optparse/argparse objects alex23 <wuwei23@gmail.com> - 2012-01-11 17:37 -0800
    Re: Introspecting optparse/argparse objects Evan Driscoll <edriscoll@wisc.edu> - 2012-01-11 20:44 -0600

csiph-web