On Fri, Apr 24, 2015 at 11:34 AM, Greg Ewing
<greg.ew...@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@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
