Rene Nejsum writes:
On 04 Oct 2016, at 18:40, Sven R. Kunze
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?