By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,898 Members | 1,162 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,898 IT Pros & Developers. It's quick & easy.

unexpected optparse set_default/set_defaults behavior

P: n/a
Some rather unexpected behavior in the set_default/set_defaults
methods for OptionParser that I noticed recently:
>>import optparse
parser = optparse.OptionParser()
parser.add_option("-r", "--restart", dest="restart", action="store_true")
<Option at 0x-483b3414: -r/--restart>
>>parser.defaults
{'restart': None}
>>parser.set_default("retart", False)
parser.defaults
{'retart': False, 'restart': None}

Why does set_default not raise an exception when passed a key that it
doesn't recognize?

Bad typysts bewaer.

The only reason I can think not to raise an exception is so that
defaults can be defined before the options are added. Is there some
use case that I'm not thinking of here? I realize that changing this
could break some existing scripts, but I'm still tempted to file this
as a bug.

Mike

Aug 17 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
mb*****@gmail.com wrote:
Some rather unexpected behavior in the set_default/set_defaults
methods for OptionParser that I noticed recently:
>>>import optparse
parser = optparse.OptionParser()
parser.add_option("-r", "--restart", dest="restart", action="store_true")
<Option at 0x-483b3414: -r/--restart>
>>>parser.defaults
{'restart': None}
>>>parser.set_default("retart", False)
parser.defaults
{'retart': False, 'restart': None}

Why does set_default not raise an exception when passed a key that it
doesn't recognize?

Bad typysts bewaer.

The only reason I can think not to raise an exception is so that
defaults can be defined before the options are added. Is there some
use case that I'm not thinking of here?
I'm not really sure what other use case there is with optparse, but
argparse has the same behavior because sometimes it's useful to store
values that can't be changed by anything on the command line. This is
particularly useful when you're dealing with sub-commands::
>>import argparse
parser = argparse.ArgumentParser()
subparsers = parser.add_subparsers()
# set up the foo parser, adding a static "func" default
>>foo_parser = subparsers.add_parser('foo')
foo_parser.set_defaults(func=lambda: 'do something for foo')
foo_parser.add_argument('--foo')
# set up the bar parser, adding a staic "func" default
>>bar_parser = subparsers.add_parser('bar')
bar_parser.set_defaults(func=lambda: 'do something for bar')
bar_parser.add_argument('bar')
# parse the arguments and call whichever "func" was selected
>>args = parser.parse_args(['bar', '13'])
args.func()
'do something for bar'

I know optparse doesn't support sub-commands, but I can imagine that if
you were trying to hack optparse to do something similar you might find
it useful to be able to specify defaults that weren't ever set by
anything at the command line.

STeVe
Aug 17 '07 #2

P: n/a
mb*****@gmail.com wrote:
Some rather unexpected behavior in the set_default/set_defaults
methods for OptionParser that I noticed recently:
[...]
Why does set_default not raise an exception when passed a key that it
doesn't recognize?

Bad typysts bewaer.

The only reason I can think not to raise an exception is so that
defaults can be defined before the options are added. Is there some
use case that I'm not thinking of here? I realize that changing this
could break some existing scripts, but I'm still tempted to file this
as a bug.
If you file it as a bug then I can assure you that you'll be told of a
long list of use-cases that depend on that feature.
Aug 18 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.