For now I can use mix asyncio.coroutines and `async def` functions, I mean I can write `await f()` inside async def to call asyncio.coroutine `f` and vise versa: I can use `yield from g()` inside asyncio.coroutine to call `async def g(): ...`.
If we forbid to call `async def` from regualr code how asyncio should work? I'd like to push `async def` everywhere in asyncio API where asyncio.coroutine required. On Wed, Apr 22, 2015 at 8:13 PM, Yury Selivanov <yselivanov...@gmail.com> wrote: > Hi Rajiv, > > On 2015-04-22 12:53 PM, Rajiv Kumar wrote: >> >> I'd like to suggest another way around some of the issues here, with >> apologies if this has already been discussed sometime in the past. >> >> From the viewpoint of a Python programmer, there are two distinct reasons >> for wanting to suspend execution in a block of code: >> >> 1. To yield a value from an iterator, as Python generators do today. >> >> 2. To cede control to the event loop while waiting for an asynchronous >> task >> to make progress in a coroutine. >> >> As of today both of these reasons to suspend are supported by the same >> underlying mechanism, i.e. a "yield" at the end of the chain of "yield >> from"s. PEPs 492 and 3152 introduce "await" and "cocall", but at the >> bottom >> of it all there's effectively still a yield as I understand it. >> >> I think that the fact that these two concepts use the same mechanism is >> what leads to the issues with coroutine-generators that Greg and Yury have >> raised. >> >> With that in mind, would it be possible to introduce a second form of >> suspension to Python to specifically handle the case of ceding to the >> event >> loop? I don't know what the implementation complexity of this would be, or >> if it's even feasible. But roughly speaking, the syntax for this could use >> "await", and code would look just like it does in the PEP. The semantics >> of >> "await <Task>" would be analogous to "yield from <Task>" today, with the >> difference that the Task would go up the chain of "await"s to the >> outermost >> caller, which would typically be asyncio, with some modifications from its >> form today. Progress would be made via __anext__ instead of __next__. > > > I think that what you propose is a great idea. However, its > implementation will be far more invasive than what PEP 492 > proposes. I doubt that we'll be able to make it in 3.5 if > we choose this route. > > BUT: With my latest proposal to disallow for..in loops and > iter()/list()-like builtins, the fact that coroutines are > based internally on generators is just an implementation > detail. > > There is no way users can exploit the underlying generator > object. Coroutine-objects only provide 'send()' and 'throw()' > methods, which they would also have with your implementation > idea. > > This gives us freedom to consider your approach in 3.6 if > we decide to add coroutine-generators. To make this work > we might want to patch inspect.py to make isgenerator() family > of functions to return False for coroutines/coroutine-objects. > > Thanks a lot for the feedback! > > Yury > _______________________________________________ > 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
