3161: add PyAny::is_exact_instance and PyAny::is_exact_instance_of r=adamreichold a=davidhewitt
Split off from #2881. I'll rebase after that merges.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2881: Rework `PyAny::is_instance_of` for performance r=adamreichold a=davidhewitt
I was talking to `@samuelcolvin` about the fastest way to identify object types (relevant e.g. for `pythonize` and also `pydantic-core`) and noticed that `PyAny::is_instance_of` is quite unoptimised because it expands to an ffi call to `PyObject_IsInstance`.
This PR proposes `PyAny::is_instance_of::<T>(obj)` is changed to be equivalent to `T::is_type_of(obj)`, plus add a sprinkling of inlining. We often have implementations such as `PyDict_Check` which can pretty much be optimised away to just checking a bit on the type object.
The accompanying benchmark to run through a bunch of object types is approx 40% faster after making this change.
For completeness, I've also added `PyAny::is_exact_instance` and `PyAny::is_exact_instance_of`, to pair with `T::is_exact_type_of`. (This could be split into a separate PR if preferred.)
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
3158: Add Py::get for GIL-independent access to frozen classes. r=davidhewitt a=adamreichold
`@davidhewitt` Is this what you had in mind for #3154?
The name is an obvious candidate for bikeshedding.
Trying to write an example, I noticed that making `PyCell::get_frozen` public is most likely not useful as there is no way to safely get a `&PyCell` without acquiring the GIL first?
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
3159: Add OpenDAL to examples r=adamreichold a=suyanhanx
Hi there,
We have been using PyO3 to build our project's python binding and have been extremely satisfied with it.
And we want to say thank you for providing such a wonderful tool.
Co-authored-by: suyanhanx <suyanhanx@gmail.com>
3150: Fix Clippy CI job cache to really include the platform. r=messense a=adamreichold
Doesn't really matter since we never build the same target on different platforms, but fixing it will prevent future confusion when reading it. Sorry for the extra lap. 😫
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
3149: Enable rust-cache on clippy CI jobs as we do for build CI jobs. r=davidhewitt a=adamreichold
Not sure if there was a reason we did not enable this for the Clippy jobs?
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
2593: docs: mention PyBuffer r=adamreichold a=davidhewitt
Uses PEP 688 `types.Buffer` to describe `PyBuffer<T>` in the conversion tables. Will leave as draft until PEP 688 is finalised.
Closes#954
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
3146: Added a few lines to document the main difference between maturin and… r=adamreichold a=why-not-try-calmer
… setuptools-rust as far as building manylinux-compliant wheels is concerned.
Co-authored-by: Adrien <mrnycticorax@gmail.com>
3029: use dynamic trampoline for all getters and setters r=adamreichold a=davidhewitt
This is an extension to the "trampoline" changes made in #2705 to re-use a single trampoline for all `#[getter]`s (and similar for all `#[setters]`). It works by setting the currently-unused `closure` member of the `ffi::PyGetSetDef` structure to point at a new `struct GetSetDefClosure` which contains function pointers to the `getter` / `setter` implementations.
A universal trampoline for all `getter`, for example, then works by reading the actual getter implementation out of the `GetSetDefClosure`.
Advantages of doing this:
- Very minimal simplification to the macro code / generated code size. It made a 4.4% reduction to `test_getter_setter` generated size, which is an exaggerated result as most code will probably have lots of bulk that isn't just the macro code.
Disadvantages:
- Additional level of complexity in the `getter` and `setter` trampolines and accompanying code.
- To keep the `GetSetDefClosure` objects alive, I've added them to the static `LazyTypeObject` inner.
- Very slight performance overhead at runtime (shouldn't be more than an additional pointer read). It's so slight I couldn't measure it.
Overall I'm happy to either merge or close this based on what reviewers think!
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2981: Remove 0.17 deprecations r=adamreichold,davidhewitt a=davidhewitt
Since #2980 starts a breaking change for 0.19, let's also clean up all 0.17's deprecations.
I've removed `Python::acquire_gil` in its own commit, as that was a reasonably chunky removal.
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
3142: Do not store return values in locals so that holders benefit from lifetime extension for temporaries. r=davidhewitt a=adamreichold
Closes#3138
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
3004: Unwrap dynamic error types when inner is simple `PyErr` r=davidhewitt,adamreichold,mejrs a=BlueGlassBlock
This is the first part of suggested improvements in #2998.
This change will make bubbled `PyErr` wrapped in `eyre::Report` / `anyhow::Error` bubble up unchanged, instead of being wrapped in a `PyRuntimeError`.
Co-authored-by: BlueGlassBlock <blueglassblock@outlook.com>
3141: Add BaseExceptionGroup for Python >= 3.11 r=adamreichold a=adriangb
Not sure if this is totally off base, but it looks like it may be this easy to add support for ExceptionGroup?
Co-authored-by: Adrian Garcia Badaracco <1755071+adriangb@users.noreply.github.com>
2980: support `text_signature` on `#[new]` r=adamreichold a=davidhewitt
Closes#2866
This is a breaking change for 0.19.0, because it starts autogenerating `text_signature` for `#[new]`. This could affect runtime behaviour if the user is relying on the class docs at runtime for some reason.
Guide & tests all updated accordingly.
`#[pyclass(text_signature = "...")]` is deprecated by this PR, however if it's set, it will be used in preference to `#[new]`.
(The signature / `text_signature` from `#[new]` will simply be ignored in this case. I figure that when users fix their deprecation warnings by removing `#[pyclass(text_signature = "...")]` then the `#[new]` signatures will start flowing properly, and this is good enough.)
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
Kang Seonghoon