On 5 October 2016 at 16:49, Rene Nejsum
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, that’s why i proposed to put the async keyword in when creating the object, saying in this instance I want asynchronous communication with the object.
OK, I think there may be a piece of foundational knowledge regarding runtime design that's contributing to the confusion here. Python's core runtime model is the C runtime model: threads (with a local stack and access to a global process heap) and processes (which contain a heap and one or more threads). Anything else we do (whether it's generators, coroutines, or some other form of paused execution like callback management) gets layered on top of that runtime model. When folks ask questions like "Why can't Python be more like Go?", "Why can't Python be more like Erlang?", or "Why can't Python be more like Rust?" and get a negative response, it's usually because there's an inherent conflict between the C runtime model and whatever piece of the Go/Erlang/Rust runtime model we want to steal. So the "async" keyword in "async def", "async for" and "async with" is essentially a marker saying "This is not a C-like runtime concept anymore!" (The closest C-ish equivalent I'm aware of would be Apple's Grand Central Dispatch in Objective-C and that shows many of the async/await characteristics also seen in Python and C#: https://www.raywenderlich.com/60749/grand-central-dispatch-in-depth-part-1 ) Go (as with Erlang before it) avoided these problems by not providing C-equivalent functions in the first place. Accordingly, *every* normal function defined in Go can also be used as a goroutine, rather than needing to be a distinct type - their special case is defining functions that interoperate with external C libraries. Python (along with other languages built on the C runtime model like C# and Objective-C) doesn't have that luxury - we need to distinguish coroutines from regular functions, since we can't just handle them according to the underlying C runtime model any more. Guido's idea of a shadow thread to let synchronous threads run coroutines without needing to actually run a foreground event loop should provide a manageable way of getting the two runtime models (traditional C and asynchronous coroutines) to play nicely together in a single application, and has the virtue of being something folks can readily experiment with for themselves before we commit to anything specific in the standard library (since all the building blocks of thread local storage, event loop management, and inter-thread message passing primitives are already available). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia