asyncio has been designed to be as "plug and play" as it gets. I'd discourage it, but one could create async loops wherever one would need them, one separate thread per loop, and adapt the code base in a more granular fashion. Blocking through the GIL will persist, though.

For any new app that is mostly IO constraint I'd still encourage the use of asyncio from the beginning.

▲

MichaelRazum 20 hours ago | parent | next [-]

Sure agree, for bi directional websocket communication it is the way to go. It's just that you have to really think it thorough when using it. Like using asyncio.sleep instead of sleep for example and there are more little things that could easily hurt the performance and advantages of it.

▲

odyssey7 2 days ago | parent | prev [-]

I remember back when the “Pythonic” philosophy was to make the language accessible.

It’s clear that Dr. Frankenstein has been at large and managed to get his hands on Python’s corpse.

	▲	kstrauser 2 days ago \| parent [-]
		I don’t think that’s fair. Yeah, there is a lot to learn and keep track of. At the same time, it’s an inherently complex problem. From one POV, and async Python program looks a lot like a cooperative multitasking operating system, but with functions instead of processes. It was a lot harder to write well-behaved programs on classic Mac OS than it was on a Commodore 64, but that Mac app was doing an awful lot more than the C64 program was. You couldn’t write them the same way and expect good results, but instead had to go about it a totally different way. It didn’t mean the Mac way was bad, just that it had a lot more inherent complexity.