On 2016-10-06 03:27, Nick Coghlan wrote:
It's not a question that's up for debate - as a point of factual history, Python's runtime model is anchored in the C runtime model, and this pervades the entire language design. Simply wishing that Python's core runtime design was other than it is doesn't make it so.
That may be true, but the limitation there is Python's core runtime model, not C's. As you say, Python's runtime model is historically anchored in C, but that doesn't mean C's runtime model itself directly constrains Python's. As others have mentioned, there are plenty of other languages that are themselves written in C but have different runtime models. The constraint is not compatibility with the C runtime model, but backward compatibility with Python's own earlier decisions about its own runtime model. This may sound like an academic point, but I just want to mention it because, as you say later, hiding C from the Python programmer is often an admirable goal. I would go so far as to say it is almost always an admirable goal. The Python runtime isn't going to suddenly change, but we can make smart decisions about incremental changes in a way that, over time, allows it to drift further from the C model, rather than adding more and more tethers linking it more tightly to the C model.
Postponing the point at which folks are confronted by those underlying C-level constraints is often an admirable goal, though - the only thing that isn't possible without fundamentally changing the language is getting rid of them entirely.
Sure. But over the long term, almost anything is possible. As I said above, my own opinion is that hiding C from Python users is almost always a good thing. I (and I think many other people) use Python because I like Python. If I liked C I would use C. To the extent that Python allows C to constrain it (or, more specifically, allows the nature of C to constrain people who are only writing Python code), it limits its ability to evolve in a way that frees users from the things they don't like about C. This is kind of tangential to the current issue about async. To be honest I am quite ignorant of how async/await will help or hurt me as a Python user. As you say, certain constraints are unavoidable. (We don't have to use C's runtime model, but we do have to be able to write our runtime model in C.) But I think it's good, when thinking about these features, to think how they will constrain future language development versus opening it up. If, for instance, people start using async/await and old-school generator-send-style coroutines become unused, it will be easier to deprecate generator-send in the distant future. On the flip side, I would hate to see decisions made that result in lots of Python code that "bakes in" specific runtime model assumptions, making it more difficult to leave those assumptions behind in the future. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown