[Python-3000] Iterators for dict keys, values, and items == annoying :)

Guido van Rossum guido at python.org
Fri Mar 24 05:17:29 CET 2006


On 3/23/06, Ian Bicking <ianb at colorstudy.com> wrote:
[...]
> To me that feels like a big transformation, where I would prefer to just
> be able to use "non_empty_lines(lines)" in place of "lines" and
> everything would work perfectly.

Well wishing ain't going to make it so. I'm not sure what you're
proposing; what you want can be done just fine by casting the iterator
to a list(). But that's not acceptable as the fundamental API because
of the premise that the whole sequence may not fit in memory. It's
clear that YOU don't care about that case, but *I* do.

[Guido]
> > If creating a copy of all items using list() is not a problem, then
> > you shouldn't have been using iterators in the first place. Iterators
> > exist so you can efficiently handle cases where list() would overflow
> > memory. If you don't have such cases, you should just design your APIs
> > to return lists in the first place.
>
> You've just made the argument that dict.keys() should return a list ;)

How so? If the dict fits in memory, the dict plus the list may not --
or it may be so tight that you end up swapping.

> Or a view would work just as well, I suppose.  Maybe you've just made
> the argument that it should return an iterable, not an iterator.

Technically an iterator is an iterable, so requiring it to return an
iterable doesn't solve your problem. Requiring a sequence or a
collection which may be a view instead of a copy *does* solve it, so I
propose to go for that. This would also solve the redundancy of having
iter(d) and iter(d.keys()) return the same thing -- d.keys() would
return a set (not multiset!) view which has other uses than either d
or iter(d).

--
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-3000 mailing list