During a call today the issue of dropping PyPy compatibility was brought up.

We currently loosely maintain PyPy compatibility (we don't test with PyPy at all), but some design/process decisions take PyPy into account. For example, currently the cython build of the scheduler requires that all annotations also work in pure python mode so it can run without cythonization. These annotations muddy the code, and don't work as well with type checkers like MyPy. Additionally, avoiding separating out the cython bits of our code makes it harder to understand what bits have been optimized for cython, and also make it harder to perform further c-extension level optimizations.

Since many users are using libraries that don't support PyPy, PyPy is likely mainly useful for speeding up the scheduler (leaving the workers running cpython). I don't know of any users running in this configuration though (most users use the same python environment for both scheduler and workers), and suspect that the maintenance burden outweighs the benefit.

As such, I suggest that we drop our (loose) PyPy compatibility requirement. This would result in no immediate changes to the codebase, but going forward we might make changes that break compatibility.