> So why is nobody doing it? Mostly, resources. Giants spent their energy speeding things strategically: ・ Google wanted Chrome to win, so they spend their e

> So why is nobody doing it? Mostly, resources. Giants spent their energy speeding things strategically: ・ Google wanted Chrome to win, so they spend their effort on JS. ・ Facebook was a PHP shop, so they worked on make it fast. ・ MS had to promote .net, so they optimized c#. Now you also have to remember that: ・ it's a hard problem ・ python is not a performance oriented language, so it was not a priority ・ when data science became popular, c-extensions were usually enough to get the perfs you wanted ・ once you have a working python code reaching perfs limit, you could start a rewrite in a fast compiled language (Google did it with go, dropbox with rust, etc). But this could take years before you need it. Youtube ran fine on PHP then Python for almost a decade. Python can take you very, very far. In fact, I'd say half the time somebody says python is too slow for them, it's because they are doing something wrong. Case in point, I have a half-million users/day streaming website running on Python. It's been running for 10 years, and needs only one dev to maintain it. ・ the PSF had no money (https://pyfound.blogspot.com/2012/01/psf-grants-over-37000-to-python.htmlhttps://pyfound.blogspot.com/2012/01/psf-grants-over-37000-to-python.html https://pyfound.blogspot.com/2012/01/psf-grants-over-37000-t...), and most work on python was from people on their free time. Very few paid devs on Python for decades, compared to other languages ・ there are actually a lot of improvements on tooling for perfs on python. Multiprocessing have fantastic pools and shared memory. We have asyncio (not to mention uvloop). c-extensions release the GIL, so you can use threads for parallelism with numpy. Most people are just not aware of it. ・ Python is very old, 4 years older than java. It has been design way before multi-core laptop were a thing. And so the GIL is everywhere. ・ python is in a very unique position: it's the second best language for anything. Meaning it's been used by data scientist, web devs, geographers, sysadmin, pen testers, os maintainers and biologists alike. They all have very different tooling, dev envs and workloads. Speed doesn't mean the same things for all of them. E.G: a slow starting JIT that speeds up a web server would destroy the use case for cli tools. Mercurial has not computational speed problems, but import time is killing it. But lazy imports would make debugging and new comers learning curve harder. What if they speed up things for them, but slow them down for you? ・ 2->3 made the entire community change averse. And to get speed, you need to break the C api somehow. Hence the Handle Python project. So the previous attempts to speed up Python were by either interns, or people doing it out of passion/curiosity. A lot failed (unladen swallow, pyston1, etc). Some were successful but only for some dimension of speed and/or doing some compromises (pypy, stackless...). Some are still WIP (Pydgin, pyston 2..). The solutions that succeeded the most are actually side stepping the problem (cython, numpy, numba, dask) but usually became popular although some very good projects still deserve more light (nuitka, mypyc...) It's only now that Python is becoming such a huge deal that MS hired Guido to work on general computational speed for cPython. Now that there is attention, money and dedication on the problem, you can already things moving in the bug tracker (coroutine unwrapping, c stack skipping calls, HandlePython, etc). It's going to take time. Millions have already been invested in V8 to make the JS slug go steroid, so catch up is not for tomorrow. > What I meant is inline. So inside of a py file, you can rewrite the one function which you identified as the bottleneck. In C or another language. You can already do that with cython. And there are alternative for rust, nim, go... That's also why python speed is usually not a priority: you can rewrite your hot spot in another language and keep most of your python code. Now, I'm glad python speed is now something the right people work on. But there were very good reason it hasn't happen until now. The way you say it, it feels like "wow, nobody has though of that before!". That's not what happened.