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 buildingcontourpy from source and use some slightly different options than the release wheels somehow. We also end up buildingnumpy 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 onaarch64, so just addedarm64 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 safehttps://matplotlib.org/stable/users/faq.html#work-with-threads
... but if there are no testsexercising 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 throughhttps://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 safehttps://matplotlib.org/stable/users/faq.html#work-with-threads ... but if there are no testsexercising 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.xgit 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 theStill Needs Manual Backport label once the PR gets merged.

If these instructions are inaccurate, feel free tosuggest an improvement.