[Python-Dev] PEP 492: async/await in Python; version 4

[Guido van Rossum]

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
> "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.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150501/e23a4a77/attachment.html>