On Fri, May 1, 2015 at 5:39 AM, Stefan Behnel email@example.com wrote:
Yury Selivanov schrieb am 30.04.2015 um 03:30:
Asynchronous Iterators and "async for"
An *asynchronous iterable* is able to call asynchronous code in its *iter* implementation, and *asynchronous iterator* can call asynchronous code in its *next* method. To support asynchronous iteration:
An object must implement an ``__aiter__`` method returning an *awaitable* resulting in an *asynchronous iterator object*.
An *asynchronous iterator object* must implement an ``__anext__`` method returning an *awaitable*.
To stop iteration ``__anext__`` must raise a ``StopAsyncIteration`` exception.
What this section does not explain, AFAICT, nor the section on design considerations, is why the iterator protocol needs to be duplicated entirely. Can't we just assume (or even validate) that any 'regular' iterator returned from "__aiter__()" (as opposed to "__iter__()") properly obeys to the new protocol? Why additionally duplicate "__next__()" and "StopIteration"?
ISTM that all this really depends on is that "__next__()" returns an awaitable. Renaming the method doesn't help with that guarantee.
This is an astute observation. I think its flaw (if any) is the situation where we want a single object to be both a regular iterator and an async iterator (say when migrating code to the new world). The __next__ method might want to return a result while __anext__ has to return an awaitable. The solution to that would be to have __aiter__ return an instance of a different class than __iter__, but that's not always convenient.
Thus, aware of the choice, I would still prefer a separate __anext__ method.