[Python-ideas] async objects

[Stephen J. Turnbull]

Nick Coghlan writes:

 > 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.

How can there be a conflict between Python implementing the C runtime
model *itself* which says "you can do anything anywhere anytime", and
some part of Python implementing the more restricted models that allow
safe concurrency?  If you can do anything, well, you can voluntarily
submit to compiler discipline to a restricted set.  No?  So it must be
that the existing constructions (functions, for, with) that need an
"async" marker have an implementation that is itself unsafe.  This
need is not being explained very well.  What is also not being
explained is what would be lost by simply using the "safe"
implementations generated by the async versions everywhere.

These may be hard to explain, and I know you, Yury, and Guido are very
busy.  But it's frustrating for all to see this go around in a circle:
"it's like it is because it has to be that way, so that's the way it is".

There's also the question of "is async/await really a language
feature, or is it patching up a deficiency in the CPython
implementation that other implementations don't necessarily have?" 
(which has been brought up before, in less contentious terms).

 > 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!"

That's understood, of course.  The question that isn't being answered
well is "why can't that non-C-like runtime concept be like Go or
Erlang or Rust?"  Or, less obtusely, "what exactly is the 'async'
runtime concept, and why is it preferred to the concepts implemented
by Go or Erlang or Rust or gevent or greenlets or Stackless?"

I guess the answer to "why not Stackless?" is buried in the archives
for Python-Dev somewhere, but I need to get back to $DAYJOB, maybe
I'll look it up later.