On Fri, Jul 12, 2002 at 07:14:21AM -0400, David Abrahams wrote:
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().
I'm not actually suggesting this as a reliable way to detect re-iterable objects, it's more of an observation. If you want something that can be relied upon for optimizations that would probably require a new __magic__ attribute. Any suggestions?
Isn't that passive/active distinction illusory though? What about __getattr__ methods?
I can't believe that any static or semi-static typing system will be able to handle __getattr__ virtual attributes. An object simply won't match a type predicate if any of the attributes checked by the predicate are virtual.
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)
I don't know what you're talking about. :-) Oren