classification
Title: Adding __iter__ to class Values of module optparse
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 2.6
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: gward Nosy List: benjamin.peterson, bethard, djc, gpolo, gward, rhettinger, shawnmorel
Priority: normal Keywords: patch

Created on 2008-03-21 15:41 by gpolo, last changed 2008-04-02 21:10 by benjamin.peterson. This issue is now closed.

Files
File name Uploaded Description Edit
optparse__iter__.diff gpolo, 2008-03-21 15:41
optparse_py3k__iter__.diff gpolo, 2008-03-21 15:48 Same patch for python 3
Messages (13)
msg64244 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2008-03-21 15:41
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.
msg64355 - (view) Author: Dirkjan Ochtman (djc) * (Python committer) Date: 2008-03-23 13:30
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.
msg64376 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2008-03-23 21:25
This seems to be a reasonable request.
msg64377 - (view) Author: Steven Bethard (bethard) * (Python committer) Date: 2008-03-23 21:37
Why can't you just iterate over ``vars(opts)``?
msg64378 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2008-03-23 21:47
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__
msg64379 - (view) Author: Steven Bethard (bethard) * (Python committer) Date: 2008-03-23 21:53
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.
msg64380 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2008-03-23 22:12
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).
msg64381 - (view) Author: Steven Bethard (bethard) * (Python committer) Date: 2008-03-23 22:17
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.
msg64851 - (view) Author: Shawn Morel (shawnmorel) Date: 2008-04-02 13:08
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
{}
>>>
msg64852 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2008-04-02 13:14
I have asked that myself, shawnmore. Why not let Value subclass dict ?
msg64862 - (view) Author: Steven Bethard (bethard) * (Python committer) Date: 2008-04-02 15:34
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().
msg64871 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2008-04-02 18:56
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.
msg64878 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-04-02 21:10
Closing on OP's request.
History
Date User Action Args
2008-04-02 21:10:48benjamin.petersonsetstatus: open -> closed
nosy: + benjamin.peterson
resolution: rejected
messages: + msg64878
2008-04-02 18:56:23gpolosetmessages: + msg64871
2008-04-02 15:34:28bethardsetmessages: + msg64862
2008-04-02 13:14:27gpolosetmessages: + msg64852
2008-04-02 13:08:46shawnmorelsetnosy: + shawnmorel
messages: + msg64851
2008-03-23 22:17:22bethardsetmessages: + msg64381
2008-03-23 22:12:47gpolosetmessages: + msg64380
2008-03-23 21:53:33bethardsetmessages: + msg64379
2008-03-23 21:47:44gpolosetmessages: + msg64378
2008-03-23 21:37:18bethardsetnosy: + bethard
messages: + msg64377
2008-03-23 21:25:54rhettingersettype: enhancement
2008-03-23 21:25:25rhettingersetassignee: gward
messages: + msg64376
nosy: + gward, rhettinger
2008-03-23 13:30:51djcsetnosy: + djc
messages: + msg64355
2008-03-21 15:48:54gpolosetfiles: + optparse_py3k__iter__.diff
2008-03-21 15:41:36gpolocreate