> > I'm happy to add the text, but i want to be clear, then: is it > > acceptable to write an iterator that only provides <next> if you > > only care about the "iteration protocol" and not the "for-able > > protocol"? > No, an iterator ought to provide both, but it's good to recognize that > there *are* two protocols. > > A class is a valid iterator object when it defines a next() > > method that behaves as described above. A class that wants > > to be an iterator also ought to implement __iter__() > > returning itself. > I would like to see this strengthened. I envision "iterator algebra" > code that really needs to be able to do a for loop over an iterator > when it feels like it. Maybe the reasons behind having __iter__() returning itself should be clearly expressed in the PEP, too. On this list, Tim gave one recently, Guido gives another here, but unless I missed it, the PEP gives none. Usually, PEPs explain the reasons behind the choices. -- 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