[Python-ideas] async objects

[Brendan Barnwell]

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