Just to add another perspective, I find many "performance" problems in the real world can often be attributed to factors other than the raw speed of the CPython interpreter. Yes, I'd love it if the interpreter were faster, but in my experience a lot of other things dominate. At least they do provide low hanging fruit to attack first. This can be anything from poorly written algorithms, a lack of understanding about the way Python works, use of incorrect or inefficient data structures, doing network accesses or other unpredictable work at import time, etc. The bottom line I think is that you have to measure what you've got in production, and attack the hotspots. For example, I love and can't wait to use Python 3.7's `-X importtime` flag to measure regressions in CLI start up times due to unfortunate things appearing in module globals. But there's something else that's very important to consider, which rarely comes up in these discussions, and that's the developer's productivity and programming experience. One of the things that makes Python so popular and effective I think, is that it scales well in the human dimension, meaning that it's a great language for one person, a small team, and scales all the way up to very large organizations. I've become convinced that things like type annotations helps immensely at those upper human scales; a well annotated code base can help ramp up developer productivity very quickly, and tools and IDEs are available that help quite a bit with that. This is often undervalued, but shouldn't be! Moore's Law doesn't apply to humans, and you can't effectively or cost efficiently scale up by throwing more bodies at a project. Python is one of the best languages (and ecosystems!) that make the development experience fun, high quality, and very efficient. Cheers, -Barry