optparse

[=?iso-8859-1?q?S=E9bastien_Boisg=E9rault?=]

Any idea why the 'options' object in

# optparse stuff
(options, args) = parser.parse_args()

is not/couldn't be a real dict ? Or why at least it
does not support dict's usual methods ?

The next move after a parse_args is often to call
a method 'do_stuff' with the args and options and
I'd like to use a call such as:

do_stuff(args, **options)

This function signature is handy if you also need
sometimes to call 'do_stuff' from the Python interpreter.

Cheers,

SB

 

[Steven Bethard]

Any idea why the 'options' object in

# optparse stuff
(options, args) = parser.parse_args()

is not/couldn't be a real dict ? Or why at least it
does not support dict's usual methods ?

Well, it's not a real dict because the original API intends it to be
used as object attributes. However, if you need a dict, it's pretty
simple -- use vars() or .__dict__:

py> import optparse
py> p = optparse.OptionParser()
py> p.add_option('-x')
<Option at 0x11a01e8: -x>
py> options, args = p.parse_args(['-x', '0'])
py> options.x
'0'
py> vars(options)
{'x': '0'}
py> options.__dict__
{'x': '0'}

STeVe

 

[=?iso-8859-1?q?S=E9bastien_Boisg=E9rault?=]

Well, it's not a real dict because the original API intends it to be
used as object attributes.

Sure . But what are the pros of this choice ? The option __str__
mimicks the behavior of a dict. Why not a full interface support
of it ?

However, if you need a dict, it's pretty
simple -- use vars() or .__dict__:

Agreed. 100%.

SB

 

[Steven Bethard]

Sure . But what are the pros of this choice ? The option __str__
mimicks the behavior of a dict. Why not a full interface support
of it ?

Well one reason might be that it's easy to convert from an object's
attributes to a dict, while it's hard to go the other direction:

py> options.x, options.y
('spam', 42)
py> vars(options) # convert to dict
{'y': 42, 'x': 'spam'}

versus

py> options['x'], options['y']
('spam', 42)
py> o = ??? # convert to object???
....
py> o.x, o.y
('spam', 42)

Though I had been working on a namespace module[1] with Nick Coghlan and
Carlos Ribeiro that provided such behavior:

py> options['x'], options['y']
('spam', 42)
py> o = namespace.Namespace(options)
py> o
Namespace(x='spam', y=42)
py> o.x, o.y
('spam', 42)

However, the namespace module is not part of the Python stdlib, so by
providing an object with attributes instead of a dict, optparse supports
(using only builtin functions) both users that want an object with
attributes and users that want a dict.

STeVe

[1] http://namespace.python-hosting.com/

 

[Andrew Dalke]

Well one reason might be that it's easy to convert from an object's
attributes to a dict, while it's hard to go the other direction: ...
py> options['x'], options['y']
('spam', 42)
py> o = ??? # convert to object???
...
py> o.x, o.y
('spam', 42)

"hard" == "slightly less easy"?

class Spam:
def __init__(self, d):
self.__dict__.update(d)

then

o = Spam(options)

or use the types module (if you have a classic class)

My guess is the original intent was to make the command-line
parameters act more like regular variables. They are easier
to type (x.abc vs. x["abc"]) and the syntax coloring is different.


Andrew
(e-mail address removed)

 

[Steven Bethard]

Well one reason might be that it's easy to convert from an object's
attributes to a dict, while it's hard to go the other direction:
...

py> options['x'], options['y']
('spam', 42)
py> o = ??? # convert to object???
...
py> o.x, o.y
('spam', 42)

"hard" == "slightly less easy"?

No, sorry, "hard" -> "harder". Typo. For simple cases like this, it's
obviously not difficult, though it does take more work than the opposite
direction.

If you didn't catch the old discussions about some of the details, I
think they're under something like "generic objects" or "namespace
objects". You can check the archives if you're interested.

STeVe