[Python-ideas] async objects

[Stephen J. Turnbull]

Rene Nejsum writes:
 > On 04 Oct 2016, at 18:40, Sven R. Kunze <srkunze at mail.de> wrote:

 > > I don't think that's actually what I wanted here. One simple
 > > keyword should have sufficed just like golang did. So, the
 > > developer gets a way to decide whether or not he needs it
 > > blocking or nonblocking **when using a function**. He doesn't
 > > need to decide it **when writing the function**.
 > 
 > I agree,

I don't believe it's true, but suppose it is.  *You don't need
syntactic support* (a keyword) for it.  Do you?  It can all be done
conveniently and readably with functions, as you have proved yourself
with pyworks and Sven has with xfork, not to forget greenlets and
gevent.  No?

You could argue that coroutines don't require syntax (keywords)
either, but some Very Smart People disagree.  I don't understand PEP
492's implementation well, but pretty clearly there are blockers to
allowing ordinary __next__ methods doing async calls.  There's also
the issue mentioned in PEP 3153 that generators don't fit the notion
of (self-actuated) producers "pushing" values into other code; they're
really about having values pulled out of them.  So PEPs 3156 and 492
are actual extensions to Python's capabilities for compact, readable
expression of [a specific idiom/model of] asynchronous execution.
They aren't intended for all possible models, just to help with one
that is important to a fairly large class of Python programmers.

 > I think that the model of doing async should be defined in the
 > Python language/runtime (like in Go, Erlang, ABCL) .

Why be restrictive?  Python already supports many models of
concurrency, pretty much filling the space (parallel execution vs.
coroutines, shared-state vs. isolated, cooperative vs. preemptive,
perhaps there are other dimensions).  Why go backward from where we
already are?