ci: start testing on 3.13-dev

[davidhewitt]

Now that 3.13 beta 1 is out, we should really look at testing 3.13. Let's start by running in CI and see what happens...

[codspeed-hq]

CodSpeed Performance Report

Merging #4184 will not alter performance

_{Comparing davidhewitt:3.13-dev (5209e6f) with main (7790dab)}

Summary

✅ 68 untouched benchmarks

[davidhewitt]

For now I'd like to merge this PR with this flag set, but I think for users to do real testing with 3.13 we shouldn't ask them to set this.

[alex]

Is the idea that we'd merge this as is, get the tests passing, and then declare support and remove this?

[davidhewitt]

Yes, it looks like there are some test cases to fix beyond the FFI changes which I tested locally.

I'm not totally sure what "support" looks like. We don't expect ABI changes any more, but it's possible, and unlike programs using the headers which will compile fine if there's a slight adjustment, we'd have an ABI incompatibility.

Maybe that's fine and we just declare 3.13 support anyway as good enough, or maybe we need an opt-in to 3.13 prereleases and save declaring full 3.13 support until after the release (or the RC).

[henryiii]

Last beta is always the ABI stable point.

[davidhewitt]

I had a quick chat with @hugovk today at PyCon. What I took from that conversation is that, as you say, there should be no ABI breaks, and it's desirable for packages to start uploading PyPI so that downstream code can get testing.

So all in all, the feeling was that we should get on with declaring 3.13 support and the CPython release team are ok with the unlikely possibility that there may be changes which cause breakages of early wheels.

I'll take a look at the test break and see if I can get this PR totally green.

[henryiii]

FYI, the manylinux images have a free threading build if you need it.

[davidhewitt]

FYI, the manylinux images have a free threading build if you need it.

Thanks, great to know! I will hopefully be looking into that before long...

[davidhewitt]

🎉 looks like this is ready! I think there's a lot of FFI cleanup yet to be actioned, but that can happen later as a follow-up ticket. Here I just did enough to get CI green.

[davidhewitt]

Anyone want to give this a review before I click to merge? It would be nice to proceed towards unblocking downstream!

[henryiii]

I notice pyo3-ffi/src/ceval.rs has various functions deprecated by https://peps.python.org/pep-0667/. I think only PyEval_GetBuiltins is used elsewhere, though, so I think it's fine for now (3.13 PyEval_GetLocals was leaking in pybind11). Maybe these should be updated at some point?

$ git grep -E 'PyEval_GetLocals|PyEval_GetGlobals|PyEval_GetBuiltins|\.f_locals'
pyo3-ffi/src/ceval.rs:55:    #[cfg_attr(PyPy, link_name = "PyPyEval_GetBuiltins")]
pyo3-ffi/src/ceval.rs:56:    pub fn PyEval_GetBuiltins() -> *mut PyObject;
pyo3-ffi/src/ceval.rs:57:    #[cfg_attr(PyPy, link_name = "PyPyEval_GetGlobals")]
pyo3-ffi/src/ceval.rs:58:    pub fn PyEval_GetGlobals() -> *mut PyObject;
pyo3-ffi/src/ceval.rs:59:    #[cfg_attr(PyPy, link_name = "PyPyEval_GetLocals")]
pyo3-ffi/src/ceval.rs:60:    pub fn PyEval_GetLocals() -> *mut PyObject;
src/marker.rs:682:                let builtins = ffi::PyEval_GetBuiltins();
src/marker.rs:684:                // `PyDict_SetItem` doesn't take ownership of `builtins`, but `PyEval_GetBuiltins`

Edit: Ah, didn't read the above

I think there's a lot of FFI cleanup yet to be actioned, but that can happen later as a follow-up ticket.

Perfect, never mind then. :)