@freemo Maybe they fix it in the next version

I don't know python that much, but I know when we talk about languages it take time to improve

@nate_river I dont think they have any intent. They missed their chance in the move from python2 to python3 which broke backwards compatibility and hopefully they have no intention of doing that a second time, so kinda damned if they do damned if they dont at this point.

With that said it was very doable they just choose not to do it. Even before they wrote python3 there were unofficial python interpreters that already fixed this problem and were drop-in compatible with the official python. the truth is they were just too lazy to do it.

@freemo are these things u said really things they need to fix?

Languages are created for different purposes.

That's why we use C language in avionics and we don't use PHP in this for example.

I don't know Python well enough to comment but maybe your complaint is on purpose. I know that Python is used in Machine Learning, so maybe this multprocessing plays a key role in it.

@nate_river I guess if you have no wish for people to develop cpu-limited apps on your language, then no. As you suggest and as @pganssle suggests you can (and perhaps should) write such things in C and just wrap them in python. That is a matter of opinion I suppose.

In my eyes the limitation here is not one that in any way improves python, its not a thing where they made python better in some ways by having the GIL lock issue and took that negative impact as a accepted consequence. So in that regard I do not find it excusable. It could have and should have been fixed with python3 and if they had the language would have been better (easier to write things that use multi cpus) without having any consequences... So to me and in my opinion, yes this is a black mark on the language and if they had it it would not have detracted from the intended purpose of python or made it any less suited at what its good at, it just would have made it more suited to a greater range of problems.

@freemo @nate_river By the way I did not necessarily recommend C. I've given several talks about writing Python extensions in Rust that are relevant here: https://ganssle.io/talks/#python-backend-rust

For your cases, I would guess Cython would be sufficient, and Cython is very nearly as easy to read and write as Python is.

One of Python's great strengths is that it is super easy to wrap bindings to other languages, so your API can be written in Python (easy to read and write) and your backend can be written in C or Rust or some other more complicated language.

I find there's often some 80/20 rule where 80% of the work is done by 20% of the code. Speeding up that 20% by writing it in Cython is trivial compared to writing the other 80% of the code in C or, to a lesser extent, Rust.