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

Andrew Svetlov andrew.svetlov at gmail.com
Fri Apr 24 14:55:22 CEST 2015


On Fri, Apr 24, 2015 at 11:34 AM, Greg Ewing
<greg.ewing at canterbury.ac.nz> wrote:
> 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?

No. In asyncio there is no difference between coroutine and regular
function returning future.
>From caller site next both are equal:

@asyncio.coroutine
def f():
    return 1

def g():
    fut = asyncio.Future()
    fut.set_result(1)
    return fut

Both may be called via `yield from`:
ret1 = yield from f()
ret2 = yield from g()

>
> 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
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com



-- 
Thanks,
Andrew Svetlov


More information about the Python-Dev mailing list