On Tue, 16 Jul 2002, Guido van Rossum wrote: > Yup. I regret this too. We should have had a built-in next(x) which > calls x.__next__(). Ah! I think one of the hang-ups i (we? the BOF?) got stuck on was that users of iterators would sometimes call next() directly, and so it wouldn't do to call it __next__. But it's clear to me now that a built-in next() is exactly the right answer, by analogy to the built-in repr() and method __repr__. > But yes, it's too late to change now. Sigh. Well, in the hope that it makes the change a little easier to swallow, i'll say now that if the protocol is fixed in some future version of Python, i'll volunteer to update the standard library to the new protocol. I guess when Python 3 comes around, there's going to me some sort of migration helper tool, and that tool can check for classes that have __iter__ and next, and suggest changing the name to __next__. -- ?!ng
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