The only reason other languages still have a reason for existing is because of Pythonās low performance, and the fact that it is interpreted and thus prone to unexpected run-time errors.
A rare talent to spawn an opinion more meaningless than this whole index itself.
Iām afraid this sentence is taken at face value 
The same guy went on : āThis means that safety-critical and/or real-time systems still have to rely on other languages, but in most other domains Python is slowly but surely finding its way to the top.ā
In any case, Python is indeed interpreted, very slow and, between software in a compiled language, contained in a binary, or in Python with all its dependencies and instability, my choice is quickly madeā¦
Nevertheless, Python is widely used, and when itās used for the right purpose, thatās the way it should beā¦
No doubt! Python is also single task. Consequently, I expect it to dominate in parallel programming in combination with dockers. Each Python instance is running in a separate docker containerā¦ 
With all respect to the author, the article is a nothingburger. In terms of establishing which language is more popular than the others, TIOBE Index is rather useless. [1] But in terms of establishing that a niche language got some more attention, perhaps it makes sense. Like in Adaās case.
The PLPY index shows a similar trend for a long time, with some fluctuations.
The graph is not very different to Rust, so I guess itās related with growing interest in safer and performant languages.
My guess is that the latest trend could also be (unfortunately?) related to growing defense budgets in the world, where Ada is still highly used.
Python, a single task ? See threading ā Thread-based parallelism ā Python 3.13.3 documentation
Other languages are needed to build efficient Python librairies ! (And the Python interpreter)
Then some intensive calculus funtions (Fourier Transform, Machine Learning) are programmed in C, and made available in Python (scipy, tensorflow library).
You need to take the GIL. AFAIK tasking is planned for Python 4.0.
As of Python 3.13, experimental free-threaded builds can disable the GIL, enabling true parallel execution of threads, but this feature is not available by default (see PEP 703).
Python also has another method of shared memory parallelism available since 3.12 called subinterpreters. I believe it only allows read-only access to shared memory.
Regarding general performance, the Python Performance Improvement team has implemented an experimental just-in-time compiler that is available in 3.13 but disabled by default. (See: https://www.ahmedbouchefra.com/news/python-313-2025-breakthroughs-no-gil-jit-ios-support-explained/.)
Soon, the only argument against using Python might be safety. They are making improvements with gradual typing, and Pylint is a good linter. But also, Chris Lattnerās company has been working for some years on a new compiled language called Mojo with a Python-like syntax but defaults similar to Rust in terms of safety. It has stack-based automatic memory management, and one can include ordinary Python code in the same file. It is meant to compete with C for writing fast modules that are also safe. It is pretty far along by now.
One could already write programs in it for some time, and when I last checked about a year ago, they had started adding native containers.
Not so quick! Even when programs are compiled, an important source of slowness is the dynamic typing.
At each corner the interpreter but also the equivalent compiled code has to figure out what is the current type of each object, then select the appropriate methods.
It doesnāt happen magically and is certainly computation-intensive - in some case more than the operations that are visible in the program.
It would be interesting to see how the Department of Python Efficiency handles that 
Lol, no, I donāt think they have a plan for that! But Mypy, the Python type checker (that checks optional type annotations), has an experimental compiler that uses the type annotations to try to optimize the code. I type-annotate almost all of my Python code, but I havenāt tried the Mypy compiler. There is an impediment to annotating everything in that sometimes one uses a library with modules that arenāt annotated.
Maybe theyāll manage to figure that out eventually, but it seems like most Python users, at least the ones posting in the discussion forum and answering surveys, arenāt all-in with regard to static typing.
Mojo uses static typing and type inference.
One other missing feature in Python that I forgot to mention is stability. I decided to move away from Python for my open source research prototype because of that. Sometimes research software becomes useful or timely years after it was written, and Iād like it to still work (even if Iām too busy with other things to maintain it). I noticed the problem when I upgraded from using Python 3.9 to 3.12 in order to try to take advantage of some claimed potential speed improvements and it wouldnāt compile right away. I had to work around a removed standard library module that one of my dependencies was depending on. After I got it compiling, I had to make a minor fix in another third-party library that was no longer behaving as expected. That project was the first time Iād used Python for a whole project more than one file (essentially more than a script).
Where I work, Iām the only Python-speaker who even seems aware of type annotations. I donāt think the average scientist relying on, say, numpy will be moving to type annotations anytime soon.
And yeah, the lack of annotations in support libraries is a drag. Some of the more commonly used and important ones have stepped up to the plate, though, such as numpy.
Would that happen to be the cgi library? That one burned me recently. I suspect it wasnāt, since I found a workaround for that, but itās a fundamental part of a UI library that is not only recommended by quite a few websites, it is part of other UI libraries.
It wasnāt the cgi library. I donāt remember the details clearly now. I remember that I was using a library called āatomicā that depended on Cython, and Cython depended on something removed from Python in 3.12. I solved it by removing atomic. It wasnāt essential. (I donāt think it prevented any important races.)
I assume that everything that relied on Cython wouldnāt work with 3.12 for a while.
I looked at the removal list in the Python documentation, and I remembered that I saw an error that the module āimpā wasnāt found and that when looking into it I found that it had been replaced by āimportlibā. I donāt remember if that was part of the same or a different issue.