Please don't take this as "why u no faster?!" as much as I really would enjoy understanding what it takes to bring pypy up to cpython parity. I do see https://doc.pypy.org/en/latest/contributing.html#your-first-... says that pypy has a lot of layers and (I'd suppose) a fraction of the number of people compared to cpython's contributor base, but like I said it's hard to understand from the outside whether it's just a lot of rocks to break, or there are genuine novel optimization or computer science tricks that have to be solved when rolling out a newer version
Above all, thanks so much for your work on pypy - it has really helped me a lot and not from its speed but from my ability to use in in places where getting cpython to run is harder than "curl pypy.tar.bz2 | tar -xjf"
I am glad you find PyPy useful. The good news is exactly the boring consistency with which we have been able, on a volunteer basis, to stay pretty close to CPython progress. There are no big challenges there, it is work at the top layer of the interpreter to adapt current code to CPython changes. On the other hand, we need sponsorship to implement the deeper changes we would like to make that would make things even faster.
Please don't take this as "why u no faster?!" as much as I really would enjoy understanding what it takes to bring pypy up to cpython parity. I do see https://doc.pypy.org/en/latest/contributing.html#your-first-... says that pypy has a lot of layers and (I'd suppose) a fraction of the number of people compared to cpython's contributor base, but like I said it's hard to understand from the outside whether it's just a lot of rocks to break, or there are genuine novel optimization or computer science tricks that have to be solved when rolling out a newer version
Above all, thanks so much for your work on pypy - it has really helped me a lot and not from its speed but from my ability to use in in places where getting cpython to run is harder than "curl pypy.tar.bz2 | tar -xjf"