> An aside on "next" vs. "__next__": > > Note that this convention would also suggest that "next" should be > called "__next__", since "for" calls "next" implicitly. I forget > why we ended up going with "next" instead of "__next__". I think > "__next__" would have been better, especially in light of this: > > Tim Peters wrote: > > Requiring *some* method with a reserved name is an aid to > > introspection, lest it become impossible to distinguish, say, > > an iterator from an instance of a doubly-linked list node class > > that just happens to supply methods named .prev() and .next() > > for an unrelated purpose. > > This is exactly why the iterator protocol should consist of one > method named "__next__" rather than two methods named "__iter__" > (which has nothing to do with the act of iterating!) and "next" > (which is the one we really care about, but can collide with > existing method names). > > As far as i know, "next" is the only implicitly-called method of > an internal protocol that has no underscores. It's a little late > to fix the name of "next" in Python 2, though it might be worth > considering for Python 3. Yup. I regret this too. We should have had a built-in next(x) which calls x.__next__(). I think that if it had been __next__() we wouldn't have the mistake that I just discovered -- that all the iterator types that define a next() method shouldn't have done so, because you get one automatically which is the tp_iternext slot wrapped. :-( But yes, it's too late to change now. --Guido van Rossum (home page: http://www.python.org/~guido/)
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