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

[Python-Dev] PEP 3152 and yield from Future()

[Python-Dev] PEP 3152 and yield from Future() [Python-Dev] PEP 3152 and yield from Future()Greg Ewing greg.ewing at canterbury.ac.nz
Fri Apr 24 10:34:26 CEST 2015
Yury Selivanov wrote:

> It's a common pattern in asyncio when functions
> return futures.  It's OK later to refactor those
> functions to coroutines *and* vice-versa.  This
> is a fundamental problem for PEP 3152 approach.

Hmmm. So you have an ordinary function that returns
a future, and you want to turn it into a coroutine
function, but still have it return a future in
order to keep the API the same, is that right?

Turning it into a coroutine means you're going
to have to change every site that calls it, so
its API has already changed. Given that, I'm not
sure what advantage there is in keeping the future-
returning part of the API.

However, if we use the await()-cofunction idea,
then a call to the initial version looks like

    cocall await(f(x))

and after the refactoring it becomes

    cocall await(cocall f(x))

That doesn't look so bad to me.

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