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@python.org> wrote:
On Mon, Oct 29, 2012 at 7:29 PM, Yury Selivanov <yselivanov.ml@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