On 11/22/2014 06:31 AM, Nick Coghlan wrote: > > A particularly relevant variant of the idiom is the approach of writing > "__iter__" directly as a generator, rather than creating a separate custom > iterator class. In that context, the similarities between the __iter__ > implementation and the corresponding explicit __next__ implementation is a > beneficial feature. https://docs.python.org/3/reference/datamodel.html?highlight=__iter__#object.__iter__ -------------------------------------------------------------------------------------- > This method is called when an iterator is required for a container. > This method should return a new iterator object that can iterate > over all the objects in the container. For mappings, it should > iterate over the keys of the container, and should also be made > available as the method keys(). > Iterator objects also need to implement this method; they are > required to return themselves. For more information on iterator > objects, see Iterator Types. Unless the object is itself at iterator, the __iter__ method is allowed to return any iterator object; whether that iterator is constructed by a separate class entirely, or by using the iter() function, or by writing a generator, should have no bearing on how we write generators themselves. -- ~Ethan~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://mail.python.org/pipermail/python-dev/attachments/20141122/bbe8bbdc/attachment.sig>
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