[Python-Dev] PEP 492: async/await in Python; version 4
Guido van Rossum
guido at python.org
Fri May 1 17:28:07 CEST 2015
On Fri, May 1, 2015 at 5:39 AM, Stefan Behnel <stefan_ml at behnel.de> 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:
> > 1. An object must implement an ``__aiter__`` method returning an
> > *awaitable* resulting in an *asynchronous iterator object*.
> > 2. An *asynchronous iterator object* must implement an ``__anext__``
> > method returning an *awaitable*.
> > 3. 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
> 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.
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev