[Python-ideas] async objects

[Nick Coghlan]

On 5 October 2016 at 16:49, Rene Nejsum <rene at stranden.com> wrote:
>> 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, 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 at gmail.com   |   Brisbane, Australia