Conventions for iterators

jlbec at jlbec at
Fri Feb 1 03:20:57 CET 2002

	I was wondering what (if any) were the conventions used when
generating iterators.  I know the next()/StopIteration protocol.  I'm
speaking more of consistency conventions.
	Say I have a list-like object containing the objects (obj1,
obj2, obj3, obj4, obj5).  Each successive iteration returns the next
object.  Pretty simple.  However, what if I call
"listthing.delete(cur_obj)", where cur_obj is the current object
returned by the iteration?  There are many things that *could* happen
(let's say that cur_obj is obj3).

1. Stop iterating, because the change renders the iterator invalid.
2. The next element (obj4) is correctly iterated.
3. The internal structure isn't exactly a list, so the next element
   (when queried) now may be obj2 again, or might skip obj4 to obj 5)
4. The list-like object is broken due to a state inconsistency created

	Now, obviously, 3 and 4 are bad.  In fact, 1 is a solution to
both of them.  If you know the state will be "bad", fire StopIteration.
However, that is pretty unusable.  With "one modification invalidates
the iterator," you cannot have code like:

for item in list:
    if matches(item):

So, obviously, behavior 2 is "best."  But I was wondering what the
python community expects/requires.  Is the idiom such that solution 2 is
"required," and everyone will expect an object's iterator to work that
way, or is it more of a caveat emptor situation, and you had better red
the module's documentation to see how the module handles this situation?
	Dog, that's a long sentence.


"The trouble with being punctual is that nobody's there to
 appreciate it"  - Franklin P. Jones
				Joel Becker <jlbec at>

More information about the Python-list mailing list