From: "Oren Tirosh" firstname.lastname@example.org
On Fri, Jul 12, 2002 at 06:22:05AM -0400, David Abrahams wrote:
I like the direction this is going in, but I have some reservations
any protocol which requires users to avoid using a simple method name
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
realize this involves actually invoking the __iter__ method and
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
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)