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. -- http://mail.python.org/mailman/listinfo/python-list