[Moore, Paul] > - I'm +0 on dropping the requirements that iterators *must* > implement __iter__() (as per your description of the 2 > orthogonal proposals). In Ka-Ping's letter, I did not read that the proposals were orthogonal. __iter__ would not be required anymore to identify an iterator as such, because __next__ would be sufficient, alone, for this purpose. That would have the effect of cleaning up the iterator protocol from the double constraint it currently has, and probably makes things clearer as well. > I'd like to see iterators strongly advised to implement __iter__() as > returning self Strong advice should not be merely given "ex cathedra", there should be some kind of (convincing) justification behind it. It makes sense for generators at least, so they could be used in a few places where Python expects containers to provide their iterator. The justification is more fuzzy outside generators, especially when programmers do not see the need of obtaining an iterator from itself, the usual and only case I see right now is resuming an iterator which has not bee fully consumed. Ka-Ping also stresses, indirectly, that `element in iterator' (resuming an iterator instead of obtaining a new one from a container) could have a strange meaning, and might even represent a user error. I even wonder if it would not be wise to have iterators _not_ defining an __iter__ method! -- François Pinard http://www.iro.umontreal.ca/~pinard
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