> On 06 Oct 2016, at 07:15, Stephen J. Turnbull > <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > > 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.
Agree, well put. The Erlang runtime (VM) is also written in C, so anything should be possible. I do not advocate that Python should be a “new” Erlang or Go, just saying that since we are introducing some level of concurrency in Python that we look at some of the elegant ways others have achieved this and try to implement something like that in Python. > 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”. I understand that there is a lot of backwards compatibility, especially in regards to the Python/C interface, but I think that it is possible to find an elegant solution to this. > 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?” This would be very interesting to understand. > 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. I will try to look for that, I have some time on my hands, not sure I have have the %BRAINSKILL, but never the less… br /Rene _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
