Restore PyPy testing now that PyPy supports Python 3.12

[Paolo Melchiorre]

PyPy 8.0.0 has just been released, including Python 3.12 support for the first time:

​https://pypy.org/posts/2026/09/pypy-v800-release.html

Django previously tested PyPy 3.10 in the scheduled test workflow, with both SQLite and PostgreSQL. These jobs were removed in f5772de69679efb54129ac1cbca3579b512778af when Django dropped support for Python 3.10 and 3.11 and raised its minimum supported version to Python 3.12.

Now that PyPy provides a Python 3.12 interpreter again, I propose restoring PyPy testing in Django's scheduled CI.

[Jacob Walls]

Good news! On the other hand, the main branch is going to require Python 3.14+ from January 2027, so we would immediately have to remove it again. Do you see value in testing it for four months?

[Paolo Melchiorre]

I think there is still some value in it. Restoring PyPy testing would let us verify whether Django is actually still compatible with PyPy, rather than just assuming it is.

Perhaps we could also use that to verify PyPy compatibility for the currently supported Django versions that support Python 3.12. The documentation already says that Django is compatible with PyPy versions corresponding to supported Python versions, so it would be useful to know whether that is actually true for PyPy 8.0.0.

And, more importantly, it would give us the chance to release Django 6.2 with tested compatibility with PyPy 8.0.0, even if "main" has to drop PyPy again once its minimum Python version moves beyond what PyPy currently supports.

[Carlton Gibson]

I’m a bit sceptical that we should do anything that implies pypy compatibility (and a commitment to it, which as far as I am aware we don’t have).

If someone wants to run the test suite against it and publish a blog saying “it works, but only until we drop 3.12” that would be great, but adding and then removing from CI just seems like noise.

If pypy manages to catch up and then keep up with Python’s annual release cycle, that we’ll be tracking from Django 2028 then the argument becomes different, and worth discussing again.

[Paolo Melchiorre]

I think there’s some useful context from when PyPy testing was removed in 2025.

At the time, I opened #36123 proposing that we also remove the PyPy compatibility claim from the Django documentation. My reasoning was that, since no PyPy version supported Python 3.12, Django could no longer actually test that compatibility.

Sarah closed that ticket as wontfix, pointing out that this had already been discussed in the PR and that the decision was to keep PyPy support rather than "give up" on it. See Sarah's reply.

The original PR discussion also made the intended future behavior quite explicit.

Sarah asked:

“When they do release 3.12 support ... would we backport potential fixes to keep compatibility to pypy?”

​Sarah's comment

And Mariusz replied:

“Yes, in the same way we backport support for the newest Python version.”

​Mariusz's reply

So the scenario we discussed back then has now actually happened: PyPy 8.0.0 has been released with Python 3.12 support.

My reading of that discussion is that the last explicit decision we made was to keep claiming PyPy compatibility, with the intention of restoring and maintaining it once PyPy caught up with a Python version supported by Django.

That is also what our documentation still says today:

“Django is compatible with versions of PyPy corresponding to the supported Python versions”

​Django documentation

So I think we should now follow through on that decision and at least test Django with PyPy 8.0.0 to see whether the compatibility we still document is actually true.

If we’ve changed our mind since then and no longer want to maintain PyPy compatibility, that’s also a perfectly reasonable decision to make.

But in that case I think we should make that decision explicitly and remove or qualify the compatibility statement in the documentation, rather than continuing to state it as a fact without testing it.

[Carlton Gibson]

Nice archeology.

So, yeah, at this moment I’m sceptical that we should be putting any resources into pypy support. As I’ve followed the situation, the project is kind of on life support, is seeing decreasing adoption, and most of the benefits are captured by the CPython JIT efforts. (That all may be a gross simplification, but I think the direction is correct. But do tell me otherwise.)

Given the general (I.e. widespread) concerns about capacity within Django, I think (at least) a discussion reviewing whether pypy support is on our radar currently is warranted.

[Jacob Walls]

The long delay in a 3.12 version is not reassuring. If someone identifies a legitimate incompatibility and offers a well-tested fix, we can always consider it for a backport. Until then, I don't think this brings enough value for the churn. We have failures in existing CI workflows waiting for ​triage and ​review. We can't prioritize adding and removing PyPy jobs over getting those existing jobs green.

Of course, the situation could change: once we achieve better "CI uptime" on our existing workflows, or we find larger windows than four months between a CI job being added and removed. So I'm marking "Someday/Maybe".

In the meantime, I'm happy to take a Refs #37363 -- ... PR to weaken the wording around PyPy support in the docs.

[Jacob Walls]

Replying to Jacob Walls:

In the meantime, I'm happy to take a Refs #37363 -- ... PR to weaken the wording around PyPy support in the docs.

Actually, it would be better to pursue that docs change by reopening ticket-36123. We may not need to "remove" all mentions, but simply admit that it's not practical for us to test.

[Carlton Gibson]

The Steering Council discussed this issue on Monday, 5 October 2026. We opted to close this in favour of #36123