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-May/139757.html below:

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

[Python-Dev] PEP 492: async/await in Python; version 4Ethan Furman ethan at stoneleaf.us
Fri May 1 21:19:37 CEST 2015
On 05/01, Stefan Behnel wrote:
> Yury Selivanov schrieb am 01.05.2015 um 20:52:

>> I don't like the idea of combining __next__ and __anext__.
>> In this case explicit is better than implicit.  __next__
>> returning coroutines is a perfectly normal thing for a
>> normal 'for' loop (it wouldn't to anything with them),
>> whereas 'async for' will interpret that differently, and
>> will try to await those coroutines.
> 
> Sure, but the difference is that one would have called __aiter__() first
> and the other __iter__(). Normally, either of the two would not exist, so
> using the wrong loop on an object will just fail. However, after we passed
> that barrier, we already know that the object that was returned is supposed
> to obey to the expected protocol, so it doesn't matter whether we call
> __next__() or name it __anext__(), except that the second requires us to
> duplicate an existing protocol.

If we must have __aiter__, then we may as well also have __anext__; besides
being more consistent, it also allows an object to be both a normol iterator
and an asynch iterator.

--
~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