[Python-ideas] An async facade?

[Guido van Rossum]

On Fri, Dec 21, 2012 at 2:21 PM, Jonathan Slenders <jonathan at slenders.be> wrote:
> 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?

Because once it is a Future, the scheduler has to get involved every
time it yields, even if the yield doesn't do any I/O but just
transfers control to a "subroutine". This is hard to get your head
around, but it is worth it.

> Just like @defer.inlineCallbacks in Twisted. This has the advantage that
> calling the function would simply start the coroutine.

But it would be much slower.

> 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)

Yeah, and the same works with yield from in TUlip. The @coroutine
decorator is not needed.

> 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. :)

It's water under the bridge. We have PEP 380 in Python 3.3. I don't
want to change the language again in 3.4. Maybe after that we can
reconsider.

-- 
--Guido van Rossum (python.org/~guido)