You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
title='Make sure documentation is accurate for what an (async) iterable and (async) iterator are'updated_at=<Date2021-11-22.23:09:30.137>user='https://github.com/brettcannon'
One thing I would strongly suggest for consistent terminology: Make "iterator" mean an object that has both "__next()" and "__iter()". This is consistent with how an iterator has been described in the glossary for a long time, but also consistent with (abc.collections|typing).Iterator.
Either invent a different term for objects having "__next__()" (but not necessarily "__iter__()"), or use a description like "an iterator or any other object that has a __next__() method".
Wouldn't a nicer resolution for this be to change iter (which effectively defines what is "iterable"), so that if iter does not find the __iter__ or sequence protocol, it then looks for the iterator protocol (__next__), and if it finds that, return the argument?
In that way, all iterators would automatically get the sane implementation of __iter__ by default, and we could say that in the "runtime", all iterators are iterable, matching the types. And people wouldn't need to implement __iter__ any more on their iterators i.e. the recommendation could simply be dropped).
Wouldn't a nicer resolution for this be to change iter
Unfortunately that isn't backwards-compatible. Some people may explicitly want their iterators to not be iterables to guarantee that people who want an iterator get a fresh/new one instead of reusing a live iterator.