[Python-Dev] Single- vs. Multi-pass iterability

[David Abrahams]

From: "Oren Tirosh" <oren-py-d@hishome.net>

> On Fri, Jul 12, 2002 at 06:22:05AM -0400, David Abrahams wrote:
> > Oren,
> >
> > I like the direction this is going in, but I have some reservations
about
> > any protocol which requires users to avoid using a simple method name
like
> > next() on their own multi-pass sequence types unless they intend their
> > sequence to be treated as single-pass.
>
> I'm not too thrilled about it, either, but I don't think it's too bad. If
> you implement an object with an __iter__ method you must be aware of the
> iteration protocol and the next method.  If you put a next method on an
> iterable you are most probably confusing iterators and iterables and not
> just using the name 'next' for some other innocent purpose.

People may have already written that innocent code, but I'm not sure the
consequences of misinterpreting such sequences as single-pass are so
terrible. Still, I would prefer if we were looking for "__next__" instead
of next().


> > One other possibility: if x.__iter__() is x, it's a single-pass
sequence. I
> > realize this involves actually invoking the __iter__ method and
conjuring
> > up a new iterator, but that's generally a lightweight operation...
>
> I think it is critical that all protocols should be defined by something
> passive like presence of attributes and attributes of attributes and not
by
> active probing.

Isn't that passive/active distinction illusory though? What about
__getattr__ methods?

> I don't see how a future typing system could be retrofitted
> to Python otherwise (pssst, don't tell anyone, but I'm working on such a
> system...)

Nifty! I'd love to get a preview, if possible. Types come into play at the
Python/C++ boundary, and I'm interested in how our systems will interact
(c.f. http://aspn.activestate.com/ASPN/Mail/Message/types-sig/1222793)

-Dave