[Greg Ewing] > I'd still like to see next(x) / x.__next__() in > some form in 3.0 for the sake of consistency, > though. +1 on modifying next() in Py3.0 to accept the send argument. -1 on the silly renaming to __next__ and adding __builtin__.next(). We have len() because it applies to many different object types. In contrast, next() would apply only to iterables. Foolish consistency is a somewhat weak reason to add a built-in. Also, calls to it.next() need to be as fast as possible. Adding a layer of indirection through __builtin__.next() is a waste. Raymond
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