467,077 Members | 1,089 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

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

optparse


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

Jul 19 '05 #1
  • viewed: 2243
Share:
5 Replies
Sébastien Boisgérault wrote:
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
Jul 19 '05 #2

Steven Bethard wrote:
Sébastien Boisgérault wrote:
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.


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

Jul 19 '05 #3
Sébastien Boisgérault wrote:
Steven Bethard wrote:
Sébastien Boisgérault wrote:
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.


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/
Jul 19 '05 #4
Steven Bethard wrote:
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)
import types
class Spam: pass .... o = types.InstanceType(Spam, {"x": 5, "y": 10})
o.x 5


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
da***@dalkescientific.com

Jul 19 '05 #5
Andrew Dalke wrote:
Steven Bethard wrote:
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
Jul 19 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

8 posts views Thread by Hans-Joachim Widmaier | last post: by
7 posts views Thread by Henry Ludemann | last post: by
5 posts views Thread by Norbert Thek | last post: by
3 posts views Thread by Karlo Lozovina | last post: by
3 posts views Thread by Bob | last post: by
reply views Thread by Steven Bethard | last post: by
2 posts views Thread by mbeachy@gmail.com | last post: by
reply views Thread by Robert Kern | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.