Overall I think people don’t clearly state the speed trade-off Python presents. Everyone focuses on the “40 times slower” part and nobody points out that “equivalent program in C++” is a glib false equivalence, because a truly equivalent program would have to offer all the same run-time dynamic type manipulation and nearly arbitrarily modifiable object instances involved.
What Python really proposes is this: “I’ll give you 100x more flexibility in exchange for 40x worse performance for certain classes of operations.”
Don’t want the 40x slowdown? Das cool. Code around it by using extension modules that let you specify homogeneously typed contiguous memory arrays (or bare metal structs like with ctypes or numba’s jitclass), or let you bypass CPython overhead because e.g. you know you don’t need the flexibility offered by the data model looking up a generic python function to call for an __add__ operation, and instead you can arrange for a GIL-releasing call to a pure C function. And so on.
I guess my point is that the story should be “look what Python gives you” and then “this flexibility had a cost.”
But instead it always feels more like, “this C pseudocode for this tight algorithm looks superficially similar to Python syntax for that algorithm ... but oh boy look how much slower Python is!” —- which, apart from a possible surprise when you have never looked into Python before, should be of interest to badically no one.