I agree with everything you say (in fact another post I made on this page deals with "it should be NumPy to Python" because so many people learn the language through some popular library)
I agree with your points, but the only counterpoint I will make is that Python was created as a simple scripting language that could utilize lower language code. Basically it's a convenient wrapper for faster c code. So the fact that Python is populated with scientific libraries that are optimized in c is not purely luck. That said, like a lot of things in life, it's the combination of viability and luck that lead to success.
to re-state the obvious, as a low-level C programmer by training, Python is exactly "a simple scripting language that could utilize lower language (C-linking) code." I wrote language glue for C libraries long ago, Python fit well and that is what I use it for to this day, decades later.
maybe people without the C background do not see that at all?
Maybe they do not. It's ironic that many people criticize the speed of python when it (or at least CPython) was originally made to run highly optimized C-linking code.
But I also take the Cython route when it's just one to a few functions that need optimization/parallelization... (Did you know you can instantly compile Cython in Jupyter to use with Python?). So I avoid writing anything else unless it's really necessary. (avoided* I haven't done that in a while)
The speed or lack thereof of Python is not the problem. The problem is language (mis)features.
But interestingly, Go is a very simple, straightforward language. It's got many of the same goals that Python had, and it meets those goals quite well. And it is blazingly fast. And it compiles so fast that it might as well be interpreted. And it is statically typed, something that is all the rage again these days and which Python pretends to offer but is really just noise and decoration.
I would go so far as to claim that anything built in Python can be built better in one of many other languages, even if you use Numpy or some other Python-specific language. And the way I would meet that challenge would be to isolate the use of the Python library and provide a minimal interface to that, and then call that Python program from another better language. Then I get the utility of the Python library from a language that scales better conceptually and performance-wise.
My third language was C, after Pascal and Modula 2. And I've built a good bit of production C long ago. (And beside the point, it was not difficult...? Memory management and pointer math is not rocket science. But I digress.)
It seems like the people promoting Python for its ability to interact with C (to outsource time/memory constrained functions) are no familiar with the other uses of Python -- namely to build large systems in object oriented fashions.
A 10 or 100 or even 1000 line "script" in Python is just fine. Read it like a story, let it do the one job it needs to do, and go home.
But scale up to 10000 or 100000 lines, and you will certainly be forced to go OOP. After all, most Python modules use OO classes in cases where a module of functions would suffice... Now you are in the realm where Python is comparatively very poorly suited for the job.
It's a frog-in-the-pot boiling situation. It started out innocently enough with the frog choosing the nicest small body of water nearby, but now the frog is in pain and dying and unable to understand how they got into that situation.
I agree with your points, but the only counterpoint I will make is that Python was created as a simple scripting language that could utilize lower language code. Basically it's a convenient wrapper for faster c code. So the fact that Python is populated with scientific libraries that are optimized in c is not purely luck. That said, like a lot of things in life, it's the combination of viability and luck that lead to success.