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

[Jim Jewett]

On 3/26/06, Adam DePrince <adam.deprince at gmail.com> wrote:

> [ On porting Java Iterators to python ]

Summary of my response:

Add a (convention of an) "exhausted" property that indicates
whether the iterator is used up, without wasting a value.

Add a conventional name for a reference to the underlying
collection, where there is one.

Anything beyond that feels is probably at least overkill, and
may be actively bad.

Detailed response:

These extensions seem to be useful only when the iterator
represents an underlying collection, and often only certain
types of collection, such as ordered or mapping.

If Iterators are really about views on a collection (rather than
any iterator), then it might make sense to also consider
databases and SQL.

IMHO, everything but the four basic Insert, Update, Delete,
and Select (=lookup, get) is clearly too heavyweight.  Someone
listing the members doesn't want the overhead of locking.

Inserts can be badly defined (unordered collections) or
unexpectedly expensive (insert at a position instead of
appending), so a generic interface might just be an
attractive nuisance.

Deletes already work for dictionaries as a special case.
Doing them on a list is a bad idea -- using a comprehension
expression is far more efficient.  So again, a generic
interface might just be an attractive nuisance.

Updates already work with a dictionary as a special case.
For ordered collections, either it isn't meaningful, or you
can just iterate for enum(it) instead.

> hasPrev        Yes                  Yes
> previous       Yes                  Yes

Reversible iteration seems useful.

But the original pep semi-reserved a name for it, and I haven't
seen many objects bothering to implement it; perhaps it isn't
so useful after all, in python practice.

> current        Yes                  Yes
> (the item last returned by next/prev)

How would this be used?
The only time I've wanted something like this was so that I could
write something like

    while file.readline(): ...

instead of

    for line in file: ...

and I'm not sure that my code would actually have been better
if I could have done it.

> Question #4:
>
> At first I wanted to implement Java fast-fail semantics, but now I have
> reservations.  It would require a bit of house keeping on each and evert
> insert.  IMHO, even adding as little as "flag=1" is too much for what is
> likely one of the most commonly used pieces of code in Python.  Can I
> have a show of hands?  For?  against?  Wait and see how bad the
> performance hit is before deciding?

I think an even bigger problem is either
(1)  checking isvalid on every *lookup*, or
(2)  the mess and inefficiency of forcing every (mutable) collection to
(weakly) track all its iterators, and forcing every iterator to have
methods for handling notification.  (So now "for k in dict" needs
to allocate (and deallocate) an extra weakref, and to do an extra
insert  and delete on the weakrefs list ... OK for large stable
objects like
a module, but not good for large numbers of three-item dicts.)

-jJ