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. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/