Because if you want full ecosystem compatibility with as much performance as you can squeeze given that constraint, it makes more sense to start with the constraint satisfied rather than try to work toward it.
> Oh I think NIH syndrome.
Neither CPython nor PyPy was invented at Microsoft.
The best way forward seems to be to continue to fund these existing JITs. Maybe once one is ready it can replace cpython.
Also pypy not supporting the latest python 3.5 is kind of a big deal for adoption. I would rather have 3.5 support than numpy/cpython compat but I don't do scientific computing :)
pypy has never kept up with cPython features and releases. it was always well behind the curve and did not provide essential behaviors in a timely fashion. plus it can't run any C extensions or cython code (or has to run them with emulations that erase the speed benefits), which takes a big chunk out of the available ecosystem. Example: the situation with numpy: https://doc.pypy.org/en/latest/faq.html#what-about-numpy-num...
After I ran the experimental evaluation, I had similar thoughts. If PyPy ever matches the current version of CPython I'm not sure why one wouldn't use PyPy over CPython. The biggest hurdle is matching support for popular libraries like NumPy, Tensorflow, Pandas, Scipy etc. I know they're working on supporting these, it's definitely a lot of work to do, easier said than done.
I really wish some python company invested money into making python 3.8+ compatible pypy, and running more tests on libraries for compatibility fixes. We could all use faster code.
I think the worst part is them not optimizing CPython earlier, which means that people now rely a lot on CPython internals, which means stuff like Pypy isn't compatible with the Python ecosystem. And then you end up with everyone having their Python optimization: Dropbox, Instagram, Pypy.
PyPy doesn't support Python's C API. It's more of an exercise in tracing JIT compilation (and crowdfunding various experiments) rather than a CPython replacement.
"However, I imagine a time very soon when pypy will be able to replace many cpython run programs."
Shouldn't that be the goal. Maybe something like numpy could never be fully replaced by pure python code, but it possible json/xml parsing libs and many more could.
Not all python programs are compatible with PyPy though. Nor do they get much of a performance boost by switching. Pandas and NumPy for example didn't work on PyPy until less than a year ago. And a good chunk of Python codebases are going to use one of those at some point.
Devs are already aware of PyPy. If it was as easy as being aware, everyone would switch tomorrow. The problem is that tons of code uses C extensions created with swig or python boost and those take a lot of time to port to PyPy. Another problem is that PyPy is sometimes slower/less memory efficient than CPython when you wrote the code that is optimized for CPython. That is abusing dictionaries and very limited OO use.
Because PyPy has never been a viable replacement for CPython engine in the confines of the CPython project.
For one, it would mean you'd have to throw away almost all CPython code.
Second, all the new code would be from totally different people than the CPython dev team (not very enticing).
Third, it would have compatibility issues with extensions and such.
Fourth, it would be slow calling into existing C code, which is like one of the major selling Pythons of Python (think pandas, numy, scipy, pytorch, and tons of others).
reply