Surprised that the only failures are a couple minor RMS differences on one platform only. I wonder if the contour-related tests are because we end up building contourpy from source and use some slightly different options than the release wheels somehow. We also end up building numpy from source as well. I might trying pull those from nightly temporarily.

Ah, I should have checked which tests first; those all have some increased tolerance on aarch64, so just added arm64 as well to catch Apple Silicon.

Surprised that the only failures are a couple minor RMS differences on one platform only.

Looks suprising at first given the documentation explicitly states that matplotlib isn't thread safe https://matplotlib.org/stable/users/faq.html#work-with-threads
... but if there are no tests exercising multi-threading, it is maybe not so surprising.

From my downstream point of view, it is still desirable that matplotlib be tested on 3.13t, even with no specific tests, but it will take more work to properly define which use cases are to be supported (thread-safe) and which are not.

To anyone this may interest, I recommend reading through https://py-free-threading.github.io/

Surprised that the only failures are a couple minor RMS differences on one platform only.

Looks suprising at first given the documentation explicitly states that matplotlib isn't thread safe https://matplotlib.org/stable/users/faq.html#work-with-threads ... but if there are no tests exercising multi-threading, it is maybe not so surprising.

Those were failures on 3.13, not 3.13t, so threads are unrelated.

Ow. My bad ! I don't know why I thought matplotlib was already testing (regular) 3.13. Don't mind me 😅

What is not thread safe is updating the same figure from multiple threads (e.g. updating data in one and drawing in another) because, even with the GIL the methods are not atomic and artists can be in invalid states before the methods return.

However, because we do already drop the GIL in a bunch of places in the extension code we already have low-level locks on the non-Python global state (which is the main thing that the GIL could have been protecting you from because threads can switch after any byte code) so I expect that already-thread-safe usage we will continue to be safe with free threading.

@meeseeksdev backport to v3.9.x

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

git checkout v3.9.x
git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

git cherry-pick -x -m1 7a2ea1cf0bd238785eb40d2e4b1713db65b79ede

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

git commit -am 'Backport PR #28689: ci: Enable testing on Python 3.13'

4. Push to a named branch:

git push YOURFORK v3.9.x:auto-backport-of-pr-28689-on-v3.9.x

5. Create a PR against branch v3.9.x, I would have named this PR:

"Backport PR #28689 on branch v3.9.x (ci: Enable testing on Python 3.13)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the Still Needs Manual Backport label once the PR gets merged.

If these instructions are inaccurate, feel free to suggest an improvement.