0.29 Release

[davidhewitt]

I think we're probably ready to ship the 0.29 release soon, there are a quite a number of changes now merged on main.

Some items which I would like to see done before release:

• stop inlining config into pyo3-build-config; generate directly in pyo3-ffi #5862 - this continues the work already done in Remove dependency of pyo3-macros-backend on pyo3-build-config #5809 and should improve build performance downstream
• extend pyo3-ffi-check to check functions #5965 - we have a lot of FFI changes in this release and it'd be great to audit the FFI as much as we can before shipping. Some follow ups:
  • remove more _Py private definitions from pyo3-ffi #6036
  • clean up / fix outdated private API definitions #6038
  • sync unicodeobject FFI definitions to 3.15 #6041
  • more cleanup of private FFI definitions #6042
  • check for void return FFI functions, fix incorrect cases #6043
• add PyObject_HasAttrWithError & use it in PyAnyMethods::hasattr #5944 - looks like a small and obvious cleanup
• Do not use static type references when compiling for RustPython #5995
• Introspection: add a CLI to generate stubs #5904 - getting this CLI packaged for the release will get us a workable introspection pipeline for setuptools-rust users
• Opaque PyObject ABI support #5807
  • introduce a builder for InterpreterConfig #6034 probably needs to merge first
• Publishes pyo3-introspection as a wheel on Pypi #6018 - so that we can have pyo3-introspection ship with the release
• add PyLong* API (3.14+) #6016 - seems like a good change to land, if we can decide OverflowError vs ValueError

Some correctness issues identified by Codex (a handful more incoming when I get a chance to file them):

• RustPython type imports via mutable modules can lead to type confusion #6047
• PyFrame::builtins is not guaranteed to be a dict #6048
• require capsule destructor closures to be 'static #6049
• avoid mutable references in critical_section_mutex implementations #6050

Fellow maintainers, anything else you would ideally like to see shipped?

[MatthieuDartiailh]

I am not a maintainer but I would love to get #5930 merged if I can get some help.

[bschoenmaeckers]

I would love to get #5995 into this release. It’s a the last
main blocker for RustPython.

[ngoldbaum]

3.15.0b1 comes out on Tuesday. Would you like to aim to ship non-experimental 3.15 support in 0.30?

Also worth noting that PEP 820 support in 3.15.0b1 is going to break the early PyModExport support we already merged. Maybe it makes sense to back that out? Or quickly patch in PEP 820 support and ship 0.29 to support 3.15.0b1. Either way I’ll be working on that next week.

[bschoenmaeckers]

Also worth noting that PEP 820 support in 3.15.0b1 is going to break the early PyModExport support we already merged. Maybe it makes sense to back that out? Or quickly patch in PEP 820 support and ship 0.29 to support 3.15.0b1. Either way I’ll be working on that next week.

Interesting, could you share what changed? So I can understand the possible fallout?

[ngoldbaum]

see https://peps.python.org/pep-0820/#changed-api

[bschoenmaeckers]

How much different is it from what we have implemented now?

[ngoldbaum]

Not much, we do need to add wrappers for the new PySlot struct and perhaps
spitball about the Rust API because the C API around defining slots is implemented as macros.

https://peps.python.org/pep-0820/#specification

[bschoenmaeckers]

I see thanks!

[ngoldbaum]

I opened #6012 to track the various things we'll need to do to support 3.15.0b1.

[davidhewitt]

I think it makes sense to delay 0.29 and launch it with 3.15.0b1 supported to give the ecosystem the best possible chance to prep for 3.15 over the beta/rc period.

[davidhewitt]

I updated the OP with additional details relating to #6012 and also some follow-up work from #5965.

Regarding #5930 - would definitely be great to get it in the release, but I think also getting a timely support for 3.15.0b1 out is the higher priority, (maybe early next week at the latest?), so I won't block the release on it if it slips. As noted on that PR, I think there's potential for things to go wrong if that optimization is applied incorrectly, so I'd like to handle that with due caution.

[davidhewitt]

I recently gained access to a Codex security scan for PyO3, and it's produced some reasonable findings to clear up. It seems reasonable to me that we handle these before we release. I've begun to file them & update the OP with these, will send a few more early next week.