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

[Paul Moore]

On 3/27/06, Steven Bethard <steven.bethard at gmail.com> wrote:
> On 3/26/06, Adam DePrince <adam.deprince at gmail.com> wrote:
> > I have a draft PEP and an implementation of mutable iterators for lists
> > and dicts that supports delete only.
> >
> > The PEP (Mutable Iterations) and sample code can be found at:
> >
> > http://www.deprince.net/ideas/peps.html
>
> I think the PEP really needs a much stronger motivation section,
> particularly with real-world examples of code that gets improved by
> the additional methods.  The whole discussion was spawned by a request
> for determining the length of an iterable, a problem which this PEP
> doesn't solve at all.  What problem is this PEP solving?  Is there
> real-world code where this PEP would help out?

Agreed. I don't really see the relationship between this PEP and what
went before. My understanding of the previous discussion was that
there were a few use cases, based around the need to have more
information about the underlying collection than is provided by the
minimalist iterator spec, without passing concrete collections about.

Guido referred to Java's collection framework, as a good example of
how he saw such a facility developing. The next step was the
suggestion that a PEP be written.

So, in my mind, I was expecting a PEP which defined one or more new
formal interfaces, (views) much like the iterator interface but with a
wider set of methods. The view would be backed by a concrete
collection, and the effects of view methods on on the underlying
collection would be specified (e.g., view.delete() removes the entry
from the view, and from the underlying collection, without affecting
the element which will be produced by the next application of next();
or view.length() returns the number of elements in the underlying
collection). The PEP would then go on to specify implementations to be
provided in the core - views available from dict, list and set
objects.

That's a lot of work, and possibly more than one PEP, but that's what
I imagined. The current PEP doesn't seem to  match that.

Some specific points:

- Given that most uses of d.keys/values/items are in a for loop,
there's no direct access to the iterator anyway. So the delete method
is also inaccessible. This change would require code reorganisation,
encouraging far more explicit passing round of iterators when looping.
I'm not sure that's a good thing.

- I don't see an *optional* addition to the iterator protocol as a
good thing. Functions can't assume it exists for general iterators. So
they have to be specified as taking iterators with a delete method".
Better to give the interface a proper name and be done with it.

- As Steven points out, deletion during an iteration isn't a
particularly common use case. There are others (knowing the length of
a sequence, or lookahead, for example) which are equally compelling.
Do we get a special-purpose PEP for every one, with each concrete type
growing a variety of optional iterator extensions? Python 2.x has
already rejected an optional extension to some iterators allowing them
to signal their length, as ultimately unhelpful. Better to have a
well-defined concept which is a superset of the iterator protocol
(mutable set view, say) which encapsulates a particular interface
(iterator, plus other methods including length and delete) and just
say that d.keys() returns a mutable set view.

I won't go on any more - you probably get the idea...

Paul.