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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4