KeyboardInterrupt (Ctrl+C) has been a problem wherever I've used python async. It should just work out of the box.
Python has had async for 10 years – why isn't it more popular?
81–90 of 305 posts
Re: Python has had async for 10 years – why isn't it more popular?
#82Earlier quoted context omitted.
> Code that looks synchronous, but is really async, has funny failure modes and idiosyncracies But this appears to be describing languages with green threads, rather than languages that make async explicit.
Without the "async" keyword, you can still write async code. It looks totally different because you have to control the state machine of task scheduling. Green threads are a step further than the async keyword because they have none of the function coloring stuff. You may think of use of an async keyword as explicit async code but that is very much not the case. If you want to see async code without the keyword, most…
Having to put "await" everywhere is very explicit. I'd even say it's equally explicit to a bunch of awkward closures. Why do you say it's less?
Re: Python has had async for 10 years – why isn't it more popular?
#83Why isn't it more popular ? Well, replacing libs and functions with async versions is not fun.
Re: Python has had async for 10 years – why isn't it more popular?
#84Earlier quoted context omitted.
For me, once I wanted to scale asyncio within one process (scaling horizontally on top of that), only two things made sense: rust with tokio or node.js. Doing async in python has the same fundamental design. You have an executer, a scheduler, and event-driven wakers on futures or promises. But you’re doing it in a fundamentally hand-cuffed environment. You don’t get benefits like static compilation, real work-stealin…
Or just golang?
Segfaults
Re: Python has had async for 10 years – why isn't it more popular?
#85Wow, didn't even see much about how miserable using the sync_to_async and async_to_sync transformers are.
In general, the architectures developed because of the GIL, like Celery and gunicorn and stuff like that, handles most of the problems we run into that async/await solves with slightly better horizontal scaling IMO. The problem with a lot of async code is that it tends not to think beyond the single machine that's running it, and by the time you do, you need to rearchitect things to scale better horizontally anyway.
For most Python applications, especially with web development, just start with something like Celery and you're probably fine.
Re: Python has had async for 10 years – why isn't it more popular?
#86Earlier quoted context omitted.
> Code that looks synchronous, but is really async, has funny failure modes and idiosyncracies But this appears to be describing languages with green threads, rather than languages that make async explicit.
Without the "async" keyword, you can still write async code. It looks totally different because you have to control the state machine of task scheduling. Green threads are a step further than the async keyword because they have none of the function coloring stuff. You may think of use of an async keyword as explicit async code but that is very much not the case. If you want to see async code without the keyword, most…
This is exactly what I mean.
Thank you for explaining much more clearly than I could.
> none of the function coloring stuff
And it’s this part that I don’t like (and see colleagues struggling to implement correctly at work).
Re: Python has had async for 10 years – why isn't it more popular?
#87The author gets close to what I think the root problem is, but doesn't call it out. The truth is that in python, async was too little, too late. By the time it was introduced, most people who actually needed to do lots of io concurrently had their own workarounds (forking, etc) and people who didn't actually need it had found out how to get by without it (multiprocessing etc). Meanwhile, go showed us what good green…
For me, once I wanted to scale asyncio within one process (scaling horizontally on top of that), only two things made sense: rust with tokio or node.js. Doing async in python has the same fundamental design. You have an executer, a scheduler, and event-driven wakers on futures or promises. But you’re doing it in a fundamentally hand-cuffed environment. You don’t get benefits like static compilation, real work-stealin…
GIL is not part of the language design, it's just a detail of the most common implementation - CPython.
Re: Python has had async for 10 years – why isn't it more popular?
#88Not too long ago, I read a comment on HN that suggested, due to Python's support for free-threading, async in Python will no longer be needed and will lose out to free-threading due to it's use of "colored" functions. Which seems to align with where this author ends up: > Because parallelism in Python using threads has always been so limited, the APIs in the standard library are quite rudimentary. I think there is an…
Interesting that very few people in that thread seem to understand Go's model, especially the author of this proposal. If you don't allow preemption, you still have a sort of coloring because most non async functions aren't safe to call in a virtual thread - they may block the executor. If you call C code, you need to swap out stacks and deal with blocking by potentially spawning more OS threads - that's what CGo does. Maybe preemption is harder in Python, but that's not clearly expressed - it's just rejected as obviously unwanted.
Ultimately Python already has function coloring, and libraries are forced into that. This proposal seems poorly thought out, and also too little too late.
Re: Python has had async for 10 years – why isn't it more popular?
#89I learned about the concept of async/await from JS and back then was really amazed by the elegance of it. By now, the downsides are well-known, but I think Python's implementation did a few things that made it particularly unpleasant to use. There is the usual "colored functions" problem. Python has that too, but on steroids: There are sync and async functions, but then some of the sync functions can only be called f…
I remember trying to use async in Python for the first time in 2017, and I actually found it easier to learn the basics of Go to create a coroutine, export it as a shared library, and create the bindings. I'm not exaggerating.
If I remember correctly, the Python async API was still in experimental phase at that time.
Re: Python has had async for 10 years – why isn't it more popular?
#90Earlier quoted context omitted.
For me, once I wanted to scale asyncio within one process (scaling horizontally on top of that), only two things made sense: rust with tokio or node.js. Doing async in python has the same fundamental design. You have an executer, a scheduler, and event-driven wakers on futures or promises. But you’re doing it in a fundamentally hand-cuffed environment. You don’t get benefits like static compilation, real work-stealin…
GIL is not part of the language design, it's just a detail of the most common implementation - CPython.
Fair and accurate. But that’s pretty much what people use, right?
I am happy to hear stories of using pypy or something to radically improve an architecture. I don’t have any from personal experience.
I guess twisted and stackless, a long time ago.