Introspecting optparse/argparse objects

[alex23]

On Jan 11, 11:26 am, Evan Driscoll <edrisc... at 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.