Skip to content

Releases: PyO3/pyo3

PyO3 0.23.3

04 Dec 14:46
Compare
Choose a tag to compare

This release is a soundness fix for PyO3 0.23.0 through 0.23.2.

In PyO3 0.23.0 the PYO3_CONFIG_FILE environment variable used to configure builds regressed such that changing the environment variable would no longer trigger PyO3 to reconfigure and recompile. In combination with workflows using tools such as maturin to build for multiple versions in a single build, this leads to Python wheels being compiled against the wrong Python API version.

All users who distribute artefacts for multiple Python versions are encouraged to update and rebuild with PyO3 0.23.3. Affected wheels produced from PyO3 0.23.0 through 0.23.2 are highly unstable and will crash the Python interpreter in unpredictable ways.

Aside from this fix, PyO3 0.23.3 contains some fixes to link configuration for Python 3.13t on Windows.

Thank you to the following contributors for the improvements:

@davidhewitt
@Icxolu
@kemingy

PyO3 0.23.2

25 Nov 22:25
Compare
Choose a tag to compare

This release fixes a build failure when attempting to compile for free-threaded Python when the abi3 or abi3-pyxx features are enabled. With this fix, the compile will now ignore (with a warning) the abi3 and abi3-pyxx flags (as is the case when compiling for PyPy, as neither support abi3).

This release also iterates upon the new IntoPyObject trait by adding an IntoPyObjectExt helper trait with some common convenience functions.

Finally, a compile failure related to ambiguous_associated_items lint errors inside generated #[pyclass] and #[derive(IntoPyObject)] output has been fixed.

Thank you to the following contributors for the improvements:

@davidhewitt
@LilyFoote
@ngoldbaum

PyO3 0.23.1

16 Nov 23:34
Compare
Choose a tag to compare

This is a re-release of PyO3 0.23.0 with corrections to fix docs.rs builds.

Thanks @yotamofek for the reports & fixes!

PyO3 0.23.0

15 Nov 18:46
c0f756c
Compare
Choose a tag to compare

This release is a significant iteration to both PyO3's internals and API with two major enhancements:

  • Support for Python 3.13t, also known as "free-threaded Python".
  • A new trait IntoPyObject, which unifies the existing to-Python conversion traits IntoPy and ToPyObject while also allowing new optimizations and proper error handling. The new trait also has a #[derive(IntoPyObject)] macro.

While both of these new features have undergone extensive design, it will be no surprise to find teething issues. All feedback is encouraged so that we can follow up with iterative improvements for these new features in future releases.

On top of the major additions, the removal of the "GIL Refs" API deprecated in PyO3 0.21 is now complete. A number of PyO3 APIs have had new simpler names introduced now that the PyO3 API is no longer in a migration phase (for example PyTuple::new_bound is now simplified to PyTuple::new).

Beyond that, PyO3 0.23 contains nearly 5 months of incremental improvements, bug fixes and smaller features that have been implemented while the major work of this release was ongoing.

Please consult the migration guide for help upgrading.

Thank you to everyone who contributed code, documentation, design ideas, bug reports, and feedback. The following contributors' commits are included in this release:

@abrisco
@adamcavendish
@ahlinc
@akuhnregnier
@alex
@attack68
@birkenfeld
@Brogolem35
@bschoenmaeckers
@ChayimFriedman2
@Cheukting
@csernazs
@davidhewitt
@deedy5
@dependabot[bot]
@digitalsentinel
@exg
@FlickerSoul
@gi0baro
@glevco
@Icxolu
@jakelishman
@jeff-k
@jonaspleyer
@JRRudy1
@KLMatlock
@konstin
@LilyFoote
@MatthijsKok
@Mottl
@ngoldbaum
@obi1kenobi
@Owen-CH-Leung
@sansyrox
@shehabgamin
@Stranger6667
@styvane
@Thalyum
@Tlunch
@wangxiaoying
@WilliamTakeshi
@YesSeri
@Zyell

PyO3 0.22.6

05 Nov 22:27
Compare
Choose a tag to compare

This release corrects the check for free-threaded Python introduced in PyO3 0.22.2 to prevent users accidentally installing PyO3 packages on Python 3.13t; PyO3 0.22 does not support free-threaded Python. (Stay tuned for the 0.23 release coming very soon!)

Thanks @minrk for the report and @davidhewitt for the fix!

PyO3 0.22.5

15 Oct 20:59
Compare
Choose a tag to compare

This release fixes a compile regression from 0.22.4 where #[pymethods] with name __clear__ and clear would generate code with a naming conflict. Thanks @awolverp for the report and @Icxolu for the fix!

PyO3 0.22.4

12 Oct 20:58
Compare
Choose a tag to compare

This release is a security fix for PyO3 0.22.0 through 0.22.3.

The PyWeakrefMethods trait functions for reading borrowed values from Python weak references have been identified as unsound, because they did not account for the possibility the last strong reference could be cleared at any time, leading the borrowed value to be dangling and risk of use-after-free.

PyO3 0.22.4 protects against this issue by making these methods permanently leak strong references. The methods are also marked deprecated and will be removed in PyO3 0.23. Users should switch to use the use PyWeakrefMethods functions which return owned references (the deprecation messages indicate the appropriate upgrade paths).

These functions were added in PyO3 0.22.0; all versions from 0.22.0 through 0.22.3 have been yanked.

Aside from the security fix, PyO3 0.22.4 contains a number of other bugfixes, including:

  • A fix for cases where __traverse__ functions of base types were not called when using #[pyclass(extends = ...)]
  • A fix for a regression in 0.22.3 where PyO3 generated code would trigger compile failures with crates using #![forbid(unsafe_code)]

Thank you to the following contributors for the improvements:

@davidhewitt
@ngoldbaum
@exg
@Icxolu

PyO3 0.22.3

15 Sep 20:50
Compare
Choose a tag to compare

This release contains a number of quality improvements building upon PyO3 0.22.2.

Python function calls (using .call0(), .call1(args) and .call(args, kwargs)) will now make use of the "vectorcall" calling conventions where possible, which can reduce overheads in many cases.

There have been several fix-ups to PyO3's FFI definitions. A new pyo3::ffi::compat namespace has been added which offers some backwards-compatible implementations of Python APIs otherwise normally only available on recent Pythons.

There have been numerous other bug-fixes and minor tweaks to improve user experience.

Thank you to the following contributors for the improvements:

@birkenfeld
@ChayimFriedman2
@csernazs
@davidhewitt
@Icxolu
@jakelishman
@LilyFoote
@ngoldbaum
@Zyell

PyO3 0.22.2

17 Jul 21:39
Compare
Choose a tag to compare

This release contains some minor reliability fixes building upon PyO3 0.22.1.

As PyO3 is still working on supporting freethreaded Python (upcoming in 3.13), support has been gated behind an UNSAFE_PYO3_BUILD_FREE_THREADED=1 environment variable to avoid unsuspecting users running into broken builds.

Packages built for the abi3 stable ABI will now use FFI functions for refcounting instead of inline reference count modifications on all versions of the stable ABI (previously only abi3 builds for 3.12 and up would use FFI functions). This helps mitigate interactions of old versions of the stable ABI with future CPython releases which do more complex reference counting (e.g. immortal objects, freethreaded reference counting).

The #[pymodule] declarative module now supports directly receiving options. (E.g. #[pymodule(name = "foo")], which would previously have been written as two attributes #[pymodule] #[pyo3(name = "foo")].)

A compile error on Rust 1.78 related to use of c"" literals has been fixed.

Thank you to the following contributors for the improvements:

@davidhewitt
@FlickerSoul
@gi0baro
@Icxolu
@MatthijsKok
@styvane

PyO3 0.22.1

07 Jul 06:51
59c4fa3
Compare
Choose a tag to compare

This patch release improves some cases related to new functionality in PyO3 0.22.

PartialEq<bool> has been added for Bound<'py, PyBool>.

The #[pyo3(submodule)] attribute has been added for declarative modules to stop submodules from generating an external C symbol for importing the submodule directly (which is typically never used). Declarative modules will also now correctly add items annotated with full-path attributes like #[pyo3::prelude::pyfunction].

The #[pyclass(eq)] option will no longer raise a TypeError on comparison against types not in the signature.

A #[setter] in #[pymethods] with an Option<T> input will no longer raise a deprecation warning.

A regression has been fixed in conversions for 128-bit integers on big-endian platforms.

Thank you to the following contributors for the improvements:

@alex
@davidhewitt
@jatoben
@kylebarron
@musicinmybrain
@ngoldbaum
@Owen-CH-Leung