[Python-Dev] PEP 3152 and yield from Future() (original) (raw)
Andrew Svetlov andrew.svetlov at gmail.com
Fri Apr 24 14:55:22 CEST 2015
- Previous message (by thread): [Python-Dev] PEP 3152 and yield from Future()
- Next message (by thread): [Python-Dev] PEP 3152 and yield from Future()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): [Python-Dev] PEP 3152 and yield from Future()
- Next message (by thread): [Python-Dev] PEP 3152 and yield from Future()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]