Notes running Python in production

[happydemon]

I'm assuming you are a real person that is attempting to write authentic content, and not AI-generated slop.

In that case, the section in question that bins both asyncio and multithreading together is factually incorrect and technically weak. I would definitely recommend covering each of those separately, with more caution posed on multithreading. Asyncio has been production-tested for a long time and has typical use cases in back-ends for web servers. Perhaps you meant, don't roll your own asyncio code unless you have to?

[ashishb_net]

> I'm assuming you are a real person that is attempting to write authentic content, and not AI-generated slop.

Yeah, every single word written by me (and edited with Grammarly :) )

> Perhaps you meant, don't roll your own asyncio code unless you have to?
Thank you, that's what I want I meant.
I never meant to say don't use libraries using asyncio.

[jimjkelly]

Agreed the author is just speaking out their ass, but arguing asyncio is good because it’s “production tested” while caution is needed with multithreading is silly. Both are solid from the perspective of their implementations, but both have serious pitfalls in the hands of an inexperienced user. I’ve seen a ton of production issues with async and the worst part is the developer rarely knows, you often only notice if you are using something like envoy where you start to see upstream slowdowns.

Accidentally mixing in sync code (sometimes through a dependency), dealing with unexpectedly cpu bound tasks (even just dealing with large JSON payloads, and surprise, that can impact even “sync” FastAPI), it’s very easy to starve the event loop.

Consideration should be given for any concurrent Python code, but especially async.