[Python-ideas] An async facade?
Jonathan Slenders
jonathan at slenders.be
Fri Dec 21 23:21:05 CET 2012
Just read through the PEP3156.
It's interesting to see. (I had no idea that yield from would return the
result of the generator. It's clever, given that at this point it behaves
different than a normal 'yield'.)
One question. Why does @coroutine not convert the generator into a Future
object right away?
Just like @defer.inlineCallbacks in Twisted. This has the advantage that
calling the function would simply start the coroutine.
The point of my 'await' experiment was that I could do the following:
>>> def do_something():
>>> result = await "query" # Query could be a Task object.
>>> return result
>>> do_something()
Task('do_something')
# (And there it starts executing)
It's very personal, but I find it nicer to see the name of the called
function as a Future instead of seeing a generator. Technically, coroutines
and generators may be the same, but normally you wouldn't write a for-loop
over a coroutine, and you can't make a Future of -say- an
xrange-generator. And when not calling from another coroutine (like from
the global scope during start-up), it's also a little more work to turn the
generator into a Future every time.
Here, "await" does what "yield" does. If you automatically turn coroutines
into a Future object when calling, you'll never need a "yield from" in this
case. I agree that "await" would be redundant, but somehow, if we had a
hint to the interpreter that it would turn generator functions into Future
objects during calling, that would be nice.
I'm happy to get convinced otherwise. :)
Jonathan
2012/12/21 Jonathan Slenders <jonathan at slenders.be>
> Thank you, Guido! I didn't know about this PEP, but it looks interesting.
> I'll try to find some spare time this weekend to read through the PEP,
> maybe giving some feedback.
>
> Cheers!
>
>
>
> 2012/12/21 Guido van Rossum <guido at python.org>
>
>> On Thu, Dec 20, 2012 at 3:34 PM, Jonathan Slenders <jonathan at slenders.be>
>> wrote:
>> > So, the difference is still that the "await" proposal makes the @async
>> > decorator implicit. I'm still in favor of this because in asynchronous
>> code,
>> > you can have really many functions with this decorator. And if someone
>> > forgets about that, getting a generator object instead of a Future is
>> quite
>> > different in semantics.
>>
>> Carefully read PEP 3156, and the tulip implementation:
>> http://code.google.com/p/tulip/source/browse/tulip/tasks.py . The
>> @coroutine decorator is technically redundant when you use yield from.
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121221/2ea34ef0/attachment.html>
More information about the Python-ideas
mailing list