[Python-Dev] PEP 492: What is the real goal?

[Guido van Rossum]

On Fri, May 1, 2015 at 11:26 AM, Jim J. Jewett <jimjjewett at gmail.com> wrote:

> On Thu, Apr 30, 2015 at 3:32 PM, Guido van Rossum <guido at python.org>
> wrote:
>
> (me:)
> >> A badly worded attempt to say
> >> Normal generator:  yield (as opposed to return) means
> >> that the function isn't done, and there may be more
> >> things to return later.
>
> >> but an asynchronous (PEP492) coroutine is primarily saying:
>
> >>      "This might take a while, go ahead and do something else
> >> meanwhile."
>
> (Yuri:) Correct.
>
> (Guido:)> Actually that's not even wrong. When using generators as
> coroutines, PEP 342
> > style, "yield" means "I am blocked waiting for a result that the I/O
> > multiplexer is eventually going to produce".
>
> So does this mean that yield should NOT be used just to yield control
> if a task isn't blocked?  (e.g., if its next step is likely to be
> long, or low priority.)  Or even that it wouldn't be considered a
> co-routine in the python sense?
>

I'm not sure what you're talking about. Does "next step" refer to something
in the current stack frame or something that you're calling? None of the
current uses of "yield" (the keyword) in Python are good for lowering
priority of something. It's not just the GIL, it's that coroutines (by
whatever name) are still single-threaded. If you have something
long-running CPU-intensive you should probably run it in a background
thread (or process) e.g. using an executor.


> If this is really just about avoiding busy-wait on network IO, then
> coroutine is way too broad a term, and I'm uncomfortable restricting a
> new keyword (async or await) to what is essentially a Domain Specific
> Language.
>

The common use case is network I/O. But it's quite possible to integrate
coroutines with a UI event loop.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150501/f806c251/attachment.html>