RetroSearch Browse

Fri May 1 14:39:21 CEST 2015 · https://mail.python.org/pipermail/python-dev/2015-May/139745.html

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.

Stefan

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2015-May/139745.html below:

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