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

Groups > comp.lang.python > #18794 > unrolled thread

Introspecting optparse/argparse objects

Back to article view | Back to comp.lang.python

Contents

  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

#18794 — Introspecting optparse/argparse objects

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

I'd like to be able to be able to define options and then look at the
lists. (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.) Unfortunately, there doesn't seem to be any public API for
doing this.

Even if I were to do something like
    options = [ make_option(...), make_option(...) ]
(using optparse) and could thus get a handle on the Option objects,
there doesn't seem to be a public API for retrieving stuff like the
actual options (though available via opt._short_opts and opt._long_opts).

This means that either I need to write my own wrappers around options,
option groups, and perhaps even an option parser, or I have to dig into
_variables _that _are _not _part _of _the _public _api. Both of those
choices are distasteful.

So,
1) Did I miss anything?
2) Is there some particular reason that this API *isn't* provided, and
if I asked for it I might get it in a future version?

Evan

[toc] | [next] | [standalone]

#18856

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...

> This means that either I need to write my own wrappers around options,
> option groups, and perhaps even an option parser, or I have to dig into
> _variables _that _are _not _part _of _the _public _api. Both of those
> choices are distasteful.

If you're wanting to extend the behaviour of the options, won't you
need to wrap them anyway?

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?

> 2) Is there some particular reason that this API *isn't* provided, and
> if I asked for it I might get it in a future version?

Not in optparse, as it's no longer being developed. For argparse, you
might want a better use case: adding functionality to support a
hypothetical "lack" of functionality (which is _actually_ provides)
seems like a pedantic exercise to me.

[toc] | [prev] | [next] | [standalone]

#18861

[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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web