Introspecting optparse/argparse objects

[Evan Driscoll]

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



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPDOU9AAoJEAOzoR8eZTzgQ9wH/0cvWkMcq/5qrgJBtPa4qdSJ
QKPbVh/8lkWoa9aGRUVYDnKfKHcAnoW5BzwgkDuivs8Z9ULz9jTW75RBOSsN08TD
21YtuJXbgKfUcs7E3an/z6uvE9vxqY/aXtmuUNpnhbjMyyPPvMyEL26NlT/Nh9ap
xf68m6aTlk5FgqKEg/4YlJe6suIlIpTQ38LInV6aqXL1cD3T5JmY4srW1wzSGzXm
fY/nn3m5j1KdMACm/Sq+BZ/sVwVy5e9+BmIqfvXWaxQuwnSg4QP57vTJz/caskh3
sMcdEZVXOZcUH4p+P7Sy7buOMQbFgaatnPO2kABg9yczIuk7vs/3MzsLX+8ngHs=
=v8Qo
-----END PGP SIGNATURE-----

 

[alex23]

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

 

[Evan Driscoll]

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPDkkMAAoJEAOzoR8eZTzgpQsH/Aqah/ub+YykexB0pLKT4A2y
XnRMko7SOlyoaRMGPbMgjq08hVIQEQt3XEHTDIp5O9TvPucQDe9VOrDn9OrcuExH
zfucBZmmEq3036k8pSicrXRRt6om+to/+LdDka8KRClkB2d58oZiNkNByvXzBzPD
7Tiv3Pbb+2T2NtmnMmGZs//BruaWoj9c5Rx32FareA+1W8Vz8wUyqpnP7kSZldDT
p0vYLnhJN3yMWWbyGBxr4o1ADJNPdVI7fQL+9zMZ92DS83uNp8x9CqY8zrsdXDYQ
wNGE2ZcFUy5bD6rKrHbEm82zIMKEFE2dOuECy5E8W67bTo5jEk/inAcTBog39Sg=
=UzOx
-----END PGP SIGNATURE-----