Repository navigation
Adding __iter__ to class Values of module optparse #46696
Description
| BPO | 2444 |
|---|---|
| Nosy | @rhettinger, @benjaminp, @djc |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2008-04-02.21:10:48.395>
created_at = <Date 2008-03-21.15:41:36.347>
labels = ['type-feature', 'library']
title = 'Adding __iter__ to class Values of module optparse'
updated_at = <Date 2008-04-02.21:10:48.383>
user = 'https://bugs.python.org/gpolo'bugs.python.org fields:
activity = <Date 2008-04-02.21:10:48.383>
actor = 'benjamin.peterson'
assignee = 'gward'
closed = True
closed_date = <Date 2008-04-02.21:10:48.395>
closer = 'benjamin.peterson'
components = ['Library (Lib)']
creation = <Date 2008-03-21.15:41:36.347>
creator = 'gpolo'
dependencies = []
files = ['9801', '9802']
hgrepos = []
issue_num = 2444
keywords = ['patch']
message_count = 13.0
messages = ['64244', '64355', '64376', '64377', '64378', '64379', '64380', '64381', '64851', '64852', '64862', '64871', '64878']
nosy_count = 7.0
nosy_names = ['gward', 'rhettinger', 'bethard', 'benjamin.peterson', 'gpolo', 'djc', 'shawnmorel']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue2444'
versions = ['Python 2.6']
Activity
gpolo commentedon Mar 21, 2008
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.
djc commentedon Mar 23, 2008
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.
rhettinger commentedon Mar 23, 2008
This seems to be a reasonable request.
bethard commentedon Mar 23, 2008
Why can't you just iterate over
vars(opts)?gpolo commentedon Mar 23, 2008
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__
bethard commentedon Mar 23, 2008
But
vars()is the standard Python mechanism for doing this sort ofthing (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.
gpolo commentedon Mar 23, 2008
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).
bethard commentedon Mar 23, 2008
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.
shawnmorel commentedon Apr 2, 2008
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:
gpolo commentedon Apr 2, 2008
I have asked that myself, shawnmore. Why not let Value subclass dict ?
bethard commentedon Apr 2, 2008
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().
gpolo commentedon Apr 2, 2008
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.
benjaminp commentedon Apr 2, 2008
Closing on OP's request.