Hi,

Doing (opts, args) = parser.parse_args(), supposing parser is an
OptionParser instance, gets you an instance of class Values into opts.

This patch adds the __iter__ method to the class Values so it is
possible to iterate over the options you could have received. This is
useful when all your options are required and you don't want to use a
lot of if's to check if they are all there (for example).

Right now it is possible to do this but you would have to iterate over
opts.__dict__, an ugly way as I see.

I'd like this. I had one instance where a number of options where
dynamically added to the OptionParser based on loadable modules, so that
I wanted to dynamically iterate over the Values returned as well.

This seems to be a reasonable request.

Why can't you just iterate over vars(opts)?

I consider iterating over opts to be nicer and more pythonic than using
vars(opts), since the latter is just a mask over the ugly opts.__dict__

But vars() is the standard Python mechanism for doing this sort of
thing (that is, treating an object like a dictionary). So, while I
understand that you find "iterating over opts to be nicer", calling it
more Pythonic is probably a misuse of the term. ;-)

Anyway, I should point out that optparse is maintained separately from
the standard library, and any modifications to it usually need to go
through the tracker at http://optik.sourceforge.net/ first.

There is another reason for considering __iter__ as a more pythonic
solution here. If you print opts, it may lead you to believe that it is
just a regular dict, while it is not. If you were just able to iterate
over it, I think it would be more natural. I know you could check it and
then you would know it is not a dict, but I still prefer adding
a__iter__ method over using vars here.

About optparse being maintained separately.. isn't there someone
responsible that possibly checks this bugtracker ? If it is not the
case, and if __iter__ is agreed as a good solution, I could send this to
its own bugtracker then (if that is the best thing to do).

My experience in the past has been that the optik/optparse maintainer
doesn't often respond to tickets in this tracker, though perhaps that
has changed recently.

gpolo: The argument still doesn't hold. As you point out, it's the
Values class output from __str__ and other behaviour that is being un-
pythonic and leading you to believe it's a dictionary. Adding the
__itter__ method would only make this worse. Then someone else would
surely ask to have another * method added since dictionaries support
it but values don't.

The question then is one for optik. Why doesn't values simply inherit
from dict and why does it insist on using __setattr__ rather than
actually behaving completely like a dictionary. I know I was completely surprised by the following:

>>> (opts, args) = parser.parse_args(values={})
>>> print opts
{}
>>>

I have asked that myself, shawnmore. Why not let Value subclass dict ?

Subclassing dict seems like a bad idea. The options value returned by
.parse_args() is not supposed to be dict-like, it's supposed to be
object-like. That is, the natural way of accessing values from it is
through dotted attribute access, not dict-indexing access. All the
documentation for the module makes this clear. Giving it both attribute
access and dict-indexing access would violate TOOWTDI. The One Obvious
way to get dict-indexing access from an attribute oriented object is
already vars().

Given the disagreement found here, I suggest closing this rfe and moving
further discussions to c.l.p.
Thanks djc and rhettinger for your support, and, bethard and shawnmorel
for your different p.o.v.

Closing on OP's request.