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

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

[Python-Dev] PEP 492 vs. PEP 3152, new roundGuido van Rossum guido at python.org
Sat Apr 25 00:23:07 CEST 2015
Sorry, when I wrote "future" (lower-case 'f') I really meant what Yury
calls *awaitable*. That's either a coroutine or something with an __await__
emthod.

On Fri, Apr 24, 2015 at 3:17 PM, Łukasz Langa <lukasz at langa.pl> wrote:

>
> On Apr 24, 2015, at 10:03 AM, Guido van Rossum <guido at python.org> wrote:
>
> *6. StopAsyncException*
>
> What if we required `ait.__anext__()` to return a future?
>
>
> On top of my previous response, one more thing to consider is that this
> idea brings a builtin Future back to the proposal, which has already been
> rejected in the "No implicit wrapping in Futures” section of the PEP.
>
> PEP 492 manages to solve all issues without introducing a built-in Future.
>
> --
> Best regards,
> Łukasz Langa
>
> WWW: http://lukasz.langa.pl/
> Twitter: @llanga
> IRC: ambv on #python-dev
>
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150424/c6c9f45a/attachment-0001.html>
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