Jeff Keasler wrote:
Hi,
optparse doesn't seem to have a pass-through capability for command line
parameters/options that were not registered with add_option.
I'm not the first person to complain about this. On Wed Mar 17 08:20:10
CET 2004, there's a thread titled "Perceived optparse shortcomings"
where someone complains of the same problem.
In a scripting environment, I often want to strip some of the command
line options off the argument list, and then pass the remaining options
to another module that is deeper in the tool chain.
optparse doesn't seem to allow this, as far as I can tell. It requires
that you register all possible options with add_option() or an error is
flagged. When my second tier module is an autoconf script that could
have hundreds of its own options, it seems dumb to have to register all
those options, just to have to reconvert them to command-line options so
that I can pass them to the autoconf command line.
Could we get a mode added to optparse so that any commandline
parameters/options that are not registered via add_option() can be in
the args return value of the parse_args() method?
If you code it up with unit tests and documentation, it has a good chance. But
in the meantime, you can tell optparse to stop processing options using the
standard "--" marker. For example:
$ cat mycommand.py
import optparse
parser = optparse.OptionParser()
parser.add_option('--known-option', action='store_true')
options, args = parser.parse_args()
print 'options = %r' % (options,)
print 'args = %r' % (args,)
$ python mycommand.py --known-option -- --configure-flag --other-unknown
options = <Values at 0xb4a7d8: {'known_option': True}>
args = ['--configure-flag', '--other-unknown']
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
--
http://mail.python.org/mailman/listinfo/python-list
