[game_the0ry]

Just playing devil's advocate here.

> They want some kind of performance uplift without rewriting the whole python code base.

In order take advantage of mutli-threading and/or async i/o, you would need re-write your code anyway, right? And at the point, wouldn't re-writing in different language be an option?

[biorach]

> you would need re-write your code anyway, right?

Heavily restructure, sure. Rewrite? Probably not.

[gloryjulio]

Not really. The engineering effort of rewriting the entire codebase into a different language is astronomical. Besides mapping the logic to the new language, think about all the quirks between languages that you need to deal with. In the worst cases, you have to come up entirely new code. Nobody wants to pay for that.

Upgrading the language however it's way easier, and you usually have the official upgrade guide about what to do. It's also much safer, easier to deploy and test with.

Once we have the sane multi threading path in python, there would be even less incentive to rewrite the code

[trashtester]

> Not really. The engineering effort of rewriting the entire codebase into a different language is astronomical.

Not to mention that python is actually a good language choice for many types of environments, and basically the industry standard for fields like ML/AI and supporting data pipelines.

Wherever python is used for heavy duty number crunching or large data volumes, most processing is handled by libraries written in other languages, while python is handling program flow and some small parts that need custom code. The large part can currently be quite expensive.

Migrating the whole codebase to another language for such setups would simply be absurd.

Still, for the small percentage of such codebases that DOES do semi-heavy data crunching, real multithreading would be nice so one can avoid resorting to multi-processing or implementing these parts as custom C++ libraries, or similar.