On Mon, Jul 08, 2002 at 02:44:25PM -0400, Tim Peters wrote:
I keep running into the problem that there is no reliable way to introspect about whether a type supports multi-pass iterability (in the sense that an input stream might support only a single pass, but a list supports multiple passes). I suppose you could check for __getitem__, but that wouldn't cover linked lists, for example.
Can anyone channel Guido's intent for me? Is this an oversight or a deliberate design decision? Is there an interface for checking multi-pass-ability that I've missed?
The language makes no such distinctions. If an app wants to make them, it's up to the app to implement them. Likewise for a way to tell a multipass iterator to "start over again". The Python iteration protocol has only two methods, .next() to get "the next" item, and .iter() to return self; given a random iterator, those are the only things you can rely on.
I believe that when David was talking about multi-pass iterability he wasn't referring to an iterator that can be told to "start over again" but to an iterable object that can produce multiple independent iterators of itself, each one good for a single iteration.
The language does make a distinction between an *iterable* object that may have only an __iter__ method and an *iterator* that has a next method. This distinction is blurred a bit by the fact that iterators also have an __iter__ method that also makes them appear as one-shot iterables.
Imagine an altenative universe where a south african programmer called Rossu van Guidom writes a wonderful language called Mamba and in that language iterator semantics are defined like this:
* Objects that wish to be iterable define an __iter__() method returning an iterator.
* An iterator is an object with a next() method. That's all.
* The for statement checks if an object has an __iter__ method. If it does, it calls it and uses the returned iterator. If it doesn't, it tries to use the object itself. If it doesn't have .next either it will fail and report that the object is not iterable.
A Mamba programmer called Nero Hsorit has speculated in a mamba-dev posting that in an alternative universe in a language called 'Cobra' people kept getting confused between iterators and iterables :-)