Greg Ewing <greg@cosc.canterbury.ac.nz>: > Yuck. I don't like any of this "for x in y.iterator_something()" > stuff. The things you're after aren't "in" the iterator, they're > "in" the dict. I don't want to know that there are iterators > involved. I must say I agree. Having explicit iterators obfuscates what is going on, rather than clarifying it -- the details of how we get the next item should be hidden as far below the surface of the code as possible, so programmers don't have to think about them. The only cases I know of where an explicit iterator object is even semi-justified are those where there is substantial control state to be kept around between iterations and that state has to be visible to the application code (not the case with dictionaries or any other built-in type). In the cases where that *is* true (interruptible tree traversal being the paradigm example), we would be better served with Icon-style generators or a continuations facility a la Stackless Python. I'm a hard -1 on explicit iterator objects for built-in types. Let's keep it simple, guys. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> The Constitution is not neutral. It was designed to take the government off the backs of the people. -- Justice William O. Douglas
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