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

[Paul Moore]

On 3/29/06, Brett Cannon <brett at python.org> wrote:
> Without a direct reason in terms of the language needing a
> standardization of an interface, perhaps we just don't need views.  If
> people want their iterator to have a __len__ method, then fine, they
> can add it without breaking anything, just realize it isn't part of
> the iterator protocol and thus may limit what objects a function can
> accept, but that is there choice.

Good point. I think we need to start from strong use cases. With
these, I agree that the view concept is a good implementation
technique to consider. But let's not implement views just for the sake
of having them - I'm pretty sure that was never Guido's intention.

I still think my earlier analysis is important - for loops have no
direct access to the iterator/view/whatever, and inline code has
access to the original object. So the *only* relevant use cases are
those where people are writing functions which take "extended
iterator" arguments, where those functions cannot reasonably take
either an additional argument which is the original object, or take
the original object (an iterable) *instead* of an iterator.

The key here is generators - with a generator, there is no "original
object". But then again, generators are never going to be anything
other than pure iterators, either. So you either allow them or don't,
and if you don't, you can't say you take "any iterator".

I'm still left wondering whether there are any really good use cases.
The itertools module shows how much you can do without needing more
than an iterator.

Suggestion: Start with a call for use cases, and begin the PEP with
nothing more than those. It's not normally what a PEP looks like, but
it would probably help to capture things in this case.

Paul.

PS I also wonder whether adaptation would apply here. Pass the
"original object", and the function adapts it to the view it needs.
The advantage is that it supports the idea of passing concrete objects
round, rather than partial views, while still allowing functions to be
specified in terms of a limited interface. The disadvantage is that
adaptation is still somewhat in flux, and it's possibly overkill for
this issue.