469,616 Members | 1,806 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,616 developers. It's quick & easy.

unexpected optparse set_default/set_defaults behavior

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
2 1470
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
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.

Similar topics

1 post views Thread by Andres Corrada-Emmanuel | last post: by
7 posts views Thread by Henry Ludemann | last post: by
5 posts views Thread by Sébastien Boisgérault | last post: by
7 posts views Thread by R. Bernstein | last post: by
8 posts views Thread by T | last post: by
4 posts views Thread by Karthik Gurusamy | last post: by
3 posts views Thread by Dan | last post: by
1 post views Thread by GustavoTabares | last post: by
10 posts views Thread by James | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.