A RetroSearch Logo

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

Search Query:

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

[Python-Dev] PEP 492 vs. PEP 3152, new round

[Python-Dev] PEP 492 vs. PEP 3152, new roundEthan Furman ethan at stoneleaf.us
Fri Apr 24 20:03:14 CEST 2015
On 04/24, Yury Selivanov wrote:
> On 2015-04-24 1:03 PM, Guido van Rossum wrote:

>> Ditto for `__aiter__` and `__anext__`. I guess this means that the async
>> equivalent to obtaining an iterator through `it = iter(xs)` followed by
>> `for x over it` will have to look like `ait = await aiter(xs)` followed by
>> `for x over ait`, where an iterator is required to have an `__aiter__`
>> method that's an async function and returns self immediately. But what if
>> you left out the `await` from the first call? I.e. can this work?
>> ```
>> ait = aiter(xs)
>> async for x in ait:
>>      print(x)
> 
> With the current semantics that PEP 492 proposes, "await"
> for "aiter()" is mandatory.
> 
> You have to write
> 
>     ait = await aiter(xs)
>     async for x in ait:
>         print(c)

As a new user to asyncio and this type of programming in general, 'await aiter'
feels terribly redundant.

--
~Ethan~
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4