[Python-ideas] Async API: some more code to review

[Yury Selivanov]

Guido,

Well, with such a jaw dropping benchmarks results there is no point
in discussion whether it's better to use yield-froms or yields+promises.

But let me also share results of my framework:

- Plain coroutines - 24.4
- Coroutines + greenlets - 34.5
- Coroutines + greenlets + many cython optimizations: 4.79 (still too slow)

Now with dynamically replacing (opcodes magic) 'yield' with 'yield_' to 
entirely avoid generators and some other optimizations I believe it's 
possible to speed it up even further, probably to times below 1 second.

But, again, the price of not using yield-froms is too high (and I don't even
mention hard-to-fix tracebacks when you use just yields)

On 2012-10-30, at 10:52 AM, Guido van Rossum <guido at python.org> wrote:

> On Mon, Oct 29, 2012 at 7:29 PM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
>> Couple of things I like already:
>> 
>> 1) Use of 'yield from' is completely optional
> 
> That's actually my biggest gripe...

Yes, let's use just one thing everywhere.

>> 2) @async decorator.  That makes coroutines more visible and
>> allows to add extra methods to them.
> 
> Yes on marking them more visibly. No on wrapping each call into an
> object that slows down the invocation.
> 
>> 3) Tight control over coroutines execution, something that
>> is completely missing when you use yield-from.
> 
> This I don't understand. What do you mean by "tight control"? And why
> would you want it?

Actually, if we make decorating coroutines with @coro-like decorator
strongly recommended (or even required) I can get that tight-control
thing.

It gives you the following:

- Breakdown profiling results by individual coroutines
- Blocking code detection
- Hacks to protect finally statements, modify your coroutines 
internals, etc / probably I'm the only one in the world who need this :(
- Better debugging (just logging individual coroutines sometimes helps)

And decorator makes code more future-proof as well.  Who knows what
kind of instruments you need later.

>> I dislike the choice of name for 'async', though.  Since
>> @async-decorated functions are going to be yielded most of the
>> time (yield makes them "sync" in that context), I'd stick to
>> plain @coroutine.
> 
> Hm. I think of it this way: the "async" (or whatever) function *is*
> asynchronous, and just calling it does *not* block. However if you
> then *yield* (or in my tulip proposal *yield from*) it, that suspends
> the current task until the asyc function completes, giving the
> *illusion* of synchronicity or blocking. (I have to admit I was
> confused by a comment in Steve's example code saying "does not block"
> on a line containing a yield, where I have been used to think of such
> lines as blocking.)

"*illusion* of synchronicity or blocking" -- that's precisely the reason
I don't like '@async' used together with yields.

>> P.S. If this approach is viable (optional yield-from, required
>> @async-or-something decorator), I can invest some time and
>> open source the core of my framework (one benefit is that it
>> has lots and lots of unit-tests).
> 
> Just open-sourcing the tests would already be useful!!

When the tulip is ready I simply start integrating them.

-
Yury