mattip

NumPy has a whole dispatch mechanism to deal with the tradeoffs. The main problem is code bloat: how many microarchitectures are you going to support with dispatch at runtime?

There is google’s highway, that provides an abstraction layer. It is used by NumPy.

PyPy dev here. Really cool project to convert RPython from python2 to rust. They have a long way to go, but seem to be making progress. Unfortunate name conflict with a typechrcker.

That cleanup can be explicit when needed by using context managers. Mixing resource handling with object lifetime is a bad design choice

The problem is the million small paper cuts. The stdlib changes are not all in pure python, many have implications for compiled modules like _ssl. The interpreter changes, especially compatibility with small interpreter changes that are reflected in the dis module, also require work to figure out

CFFI is fast on PyPy. The JIT still cannot peer into the compiled C/C++ code, but it can generate efficient interface code since there is a dedicated _cffi_backend module built into PyPy. Originally that was the motivation for the PyPy developers to create CFFI.

Benchmarks are tricky. Do you have a specific use case you want sped up?

- The pure python repl started off in PyPy, although a lot of work was done to make it ready for prime time by the COython core devs - The lessons from HPy are slowly making their way into CPython, see https://github.com/py-ni - There were many fruitful interactions in fixing subtle bugs in CPython that stemmed from testing the stdlib on an alternative implementation

And more

Yes. The C API those libraries use is a good fit to CPython, a bad fit to PyPy. Hence CFFI and HPy. Actually, many if the lessons from HPy are making their way into CPython since their JIT and speedups face the same problems as PyPy. See https://github.com/py-ni

Third party libraries like SciPy scikit-learn, pandas, tensorflow and pytorch have been critical to python’s success. Since CPython is written in C and exposes a nice C API, those libraries can leverage it to quickly move from (slow) python to (fast) C/C++, hitting an optimum between speed of development and speed of runtime.

PyPy’s alternative, CFFI, was not attractive enough for the big players to adopt. And HPy, another alternative that would have played better with Cython and friends came too late in the game, by that time PyPy development had lost momentum.

PyPy core dev here. If anyone is interested in helping out, either financially or with coding, we can be reached various ways. See https://pypy.org/contact.html

> Imagine how Open Source Software could improve if a consortium of nations put their money and resources into commissioning bug fixes and enhancements, which would be of collective benefit.

This is the business model of Quansight Labs, whose employees help maintain much of the scientific python stack. Mostly tech companies, not governments, sponsoring the work

There is some information transfer happening. Antonio Cuni was at the latest Coython developer sprint and shared some insights from PyPy https://antocuni.eu/2025/09/24/tracing-jits-in-the-real-worl...

PyPy v7.3.18: release of python 2.7, 3.10 and 3.11 beta

There are portable downloads of PyPy here https://pypy.org/download.html

That’s my post. Happy to answer any questions

Anyone can attend.

I think part of the point is that it doesn’t matter. You can’t preach “frugality” and @we all need to pitch in” and then use private jets and rock concerts for the few at the top. It is hypocritical.

We try to keep around useful versions of Python3, based on what wheels packagers make available. NumPy<2 provides PyPy3.9 wheels, and we have PyPy3.10 ready. Now that NumPy has moved to PyPy3.10 wheels, we will probably drop 3.9. Help is needed to move forward to 3.11/3.12.

PyPy dev here. A little money could go along way to speeding up the PyPy base interpreter. Right now PyPy has no active income.

The article is more about how to pin to prevent breakage, but also includes a link to the migration guide. A draft of the complete changeset is https://numpy.org/devdocs/release/2.0.0-notes.html. The changes move NumPy closer to the Python array API standard https://data-apis.org/array-api/latest/ which lays out a common, agreed-upon interfaces for tensor/array processing libraries.

That sounds like cffi https://cffi.readthedocs.io/en/latest/

To make it clear: this is only a proposal, not a regulation. It has a very low chance of making it into the books as it goes against the legal framework for free speech.

This minister is trying to destroy Israel’s democracy from within, and is not very well liked even by his neighbours who demonstrated outside his house every week until the war started.

While we are trying to minimize the disruptions, there is one thing project maintainers should do right now: pin the maximum NumPy to <2.0 in their ~`pyproject.toml`~ project dependencies. This will ensure they do not inadvertently upgrade before they are ready to do so. Once numpy2.0 is released, you can check that your code works with it, and then release the pin.

In what way does PyPy break compatibility?

What kind of speed up did you get?

What kind of speed up do you get?

Would love to hear more. Is it still being used?

If you find your bottlenecks in SciPy or Numpy, then PyPy will not help. Those are primarily written in C, so the PyPy JIT cannot peer inside and do any magic.

Would love to hear more. You can reach us with any of these methods https://www.pypy.org/contact.html