[Python-ideas] The async API of the future: yield-from

[Guido van Rossum]

On Fri, Oct 19, 2012 at 4:29 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Calvin Spealman wrote:
>
>> I think it is important that this is more than convention. I think that we
>> need our old friend TOOOWTDI (There's Only One Obvious Way To Do It)
>> here more than ever.
>
>
> This is part of the reason that I don't like the idea of
> controlling the scheduler by yielding instructions to it.
> There are a great many ways that such a "scheduler instruction
> set" could be designed, none of them any more obvious than
> the others.
>
> So rather than single out an arbitrarily chosen set of
> operations to be regarded as primitives that the scheduler
> knows about directly, I would rather have *no* such
> primitives in the public API.

But you have that problem anyway. In your current style you write
things like this:

        block(self.queue)
        yield

I don't see how this decouples the call site of the primitive from the
scheduler any more than if you were to write e.g. this:

        yield block(self.queue)

In fact, you can write it in your current framework and it would have
the exact same effect! That's because block() returns None, so it
comes down to calling block(self.queue) and then yielding None, which
is exactly what happens in the first form as well. And even if block()
were to return a value, since the scheduler ignores the return value
from next(), it still works the same way. Not that I recommend doing
this just because it works -- but if we liked the second form better,
we could easily implement block() in such a way that you'd *have* to
write it like that.

So, I don't see what we gain by writing it the first way.

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