> I don't know why they went with the idea that people don't need real threads like they can get in C/C++, Java, C#
Well, for one reason, the choice for Python (or the implementation we now call CPython) was made when you couldn't get what you think of as "real threads" in C/C++, and Java and C# did not yet exist.
Like many engineering choices, there are tradeoffs. The choice to implement Python memory management with reference counting and thus a global interpreter lock was made in an era when garbage collection was much less advanced, when most C libraries were not thread safe, and multi-core CPUs were mainly large computer installations.
But the world has changed in ways that make the disadvantages much more prominent. Unfortunately, efforts to remove it have failed because they slow down single-thread performance (which remains quite important) or break backward compatibility, etc.
Well, for one reason, the choice for Python (or the implementation we now call CPython) was made when you couldn't get what you think of as "real threads" in C/C++, and Java and C# did not yet exist.
Like many engineering choices, there are tradeoffs. The choice to implement Python memory management with reference counting and thus a global interpreter lock was made in an era when garbage collection was much less advanced, when most C libraries were not thread safe, and multi-core CPUs were mainly large computer installations.
As the stack overflow post https://softwareengineering.stackexchange.com/questions/1868... describes, there are advantages to an interpreter lock.
Now you know why.
But the world has changed in ways that make the disadvantages much more prominent. Unfortunately, efforts to remove it have failed because they slow down single-thread performance (which remains quite important) or break backward compatibility, etc.