2896: make rust function benchmarks more similar to the Python ones r=adamreichold a=davidhewitt
We have some benchmarks in `pytests/tests/test_pyfunctions.py` which I occasionally peek at, which compares some `#[pyfunction]` performance with pure-Python equivalents. It's designed purely to measure the overheads.
The existing comparison wasn't exactly fair because it used Rust types such as i32 on the Rust side, meaning there was additional runtime type checking going on compared to the Python implementations.
I've removed that in this PR, making all the input types on the Rust side just `&PyAny` or `Option<&PyAny>`. This does reduce the gap between the Python and Rust ones where we're slower, however it shows there is still some wins we could yet find in overhead reduction.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2897: add link on how to obtain GIL to guide r=birkenfeld a=davidhewitt
Closes#2164
Most of that issue is already addressed with the new `#[pyo3(signature = (...))]` option and its guide page. The final suggestion to make it easier to find recommendations on how to acquire the GIL seems reasonable to me.
(EDIT: original issue link was wrong)
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2895: tidy up implementation of pyclass `tp_dealloc` r=adamreichold a=davidhewitt
Just carries out a TODO to remove one level from the call stack. No external-facing changes.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2893: rename `wrap_pyfunction` impl to `wrap_pyfunction_impl` r=messense a=davidhewitt
I mistyped the other day and wrote `wrap_pyfunction(f, py)` without the `!` to invoke the macro, and `rust-analyzer` imported the hidden symbol `pyo3::impl_::pyfunction::wrap_pyfunction`. Took me a moment to realise the compilation failure was because I'd forgotten the `!`.
This PR just renames that hidden symbol to `pyo3::impl_::pyfunction::wrap_pyfunction_impl` so it doesn't clash with the user-facing macro.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2886: send errors in `__releasebuffer__` to `sys.unraisablehook` r=adamreichold a=davidhewitt
I noticed that in the `__releasebuffer__` implementation we currently diverge from documentation by allowing `-> PyResult<()>` return values, but they cause crashes later down the line.
e.g. without the other changes in this PR, the new test case would crash with the following message:
```
ValueError: oh dear
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "<string>", line 1, in <module>
SystemError: <class 'bytes'> returned a result with an exception set
```
After some deliberation I decided to allow `-> PyResult<()>` returns because:
- it keeps the macro implementation and usage simpler
- errors might be produced by the `__releasebuffer__` internals anyway (e.g. due to `PyCell` locking, or invalid self type passed)
As a result, this PR cleans up the case discussed to send errors to `sys.unraisablehook`, and updates the documentation to be clearer on the allowed behaviour.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2883: release: 0.18.0 r=davidhewitt a=davidhewitt
Release for 0.18.0
I propose to put this live on Tuesday, will merge #2882 and rebase first.
Closes#2785
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2882: inspect: gate behind `experimental-inspect` feature r=davidhewitt a=davidhewitt
This is the last thing I want to do before preparing 0.18 release.
The `pyo3::inspect` functionality looks useful as a first step towards #2454. However, we don't actually make use of this anywhere within PyO3 yet (we could probably use it for better error messages). I think we also have open questions about the traits which I'd like to resolve before committing to these additional APIs. (For example, this PR adds `IntoPy::type_output`, which seems potentially misplaced to me, the `type_output` function probably wants to be on a non-generic trait e.g. `ToPyObject` or maybe #2316.)
As such, I propose putting these APIs behind an `experimental-inspect` feature gate for now, and invite users who find them useful to contribute a finished-off design.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2879: Improve derive(FromPyObject) to apply intern! when applicable to get_item r=davidhewitt a=qbx2
This PR adds more `intern!`s to FromPyObject derive macro implementation. This should improve performance when using `#[pyo3(item)]`.
Co-authored-by: Sunyeop Lee <sunyeop97@gmail.com>
2703: deprecate required argument after `Option<T>` without signature r=davidhewitt a=davidhewitt
This PR is a follow-up to #2702 to make required arguments after `Option<T>` arguments require a `#[pyo3(signature)]` annotation to remove the possible ambiguity on whether the developer actually wanted to have a required option (which is what PyO3 is currently forced to assume).
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2871: netlify: generate all redirects automatically r=messense a=davidhewitt
Uses the versions from the pulled `gh-pages` tarball to generate the `docs.rs` redirects. Simplifies the release process.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2864: Add a section on memory management for `extension` r=davidhewitt a=haixuanTao
Adding a special case of memory management when writing an extension.
This is a documentation of: https://github.com/PyO3/pyo3/issues/1056 and https://github.com/PyO3/pyo3/issues/2853
Co-authored-by: Haixuan Xavier Tao <tao.xavier@outlook.com>
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2869: change latest URL from netlify proxy to redirect r=davidhewitt a=davidhewitt
Now that we serve all gh-pages content in netlify, it's nicer to have this as a proper redirect rather than a rewrite. Then the user can see what version of the docs they have landed on.
Closes#2867
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2868: remove fallback rewrite for netlify -> gh-pages r=davidhewitt a=davidhewitt
Instead of having a rewrite to serve all content in gh-pages but not in netlify, instead I've added a webhook so that netlify will pull and rebuild when there is a push to gh-pages.
Fixes#2850
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2678: github pages example for sys.dict modules r=davidhewitt a=flickpp
Add an example into `python_from_rust.md` for creating a module and inserting it into the `sys.modules` dictionary.
As discussed here:
GH-2649 example for inserting moulde in sys.dict
Co-authored-by: James Welchman <jamesw@plantpot.ai>
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2835: Update logging.md for logging->rust r=davidhewitt a=dylanbstorey
Demonstrates how to register a rust log consumer with a pythong logging instance.
Thank you for contributing to pyo3!
Please consider adding the following to your pull request:
- an entry for this PR in newsfragments - see [https://pyo3.rs/main/contributing.html#documenting-changes]
- docs to all new functions and / or detail in the guide
- tests for all new or changed functions
PyO3's CI pipeline will check your pull request. To run its tests
locally, you can run ```cargo xtask ci```. See its documentation
[here](https://github.com/PyO3/pyo3/tree/main/xtask#readme).
Co-authored-by: Dylan Storey <dylanbstorey@users.noreply.github.com>
2757: Updated README.md to add installation instruction for Python shared l… r=davidhewitt a=santokalayil
…ibrary on Fedora
Thank you for contributing to pyo3!
Please consider adding the following to your pull request:
- an entry for this PR in newsfragments - see [https://pyo3.rs/main/contributing.html#documenting-changes]
- docs to all new functions and / or detail in the guide
- tests for all new or changed functions
PyO3's CI pipeline will check your pull request. To run its tests
locally, you can run ```cargo xtask ci```. See its documentation
[here](https://github.com/PyO3/pyo3/tree/main/xtask#readme).
Co-authored-by: Santo K Thomas <santokalayil@gmail.com>
2849: Relax indexmap dependency r=adamreichold a=gnaaman-dn
Halloo,
Noticed some version resolve errors when trying to use the `indexmap` features.
```bash
❯ cargo add pyo3 --features indexmap
❯ cargo add serde_yaml
Updating crates.io index
Adding serde_yaml v0.9.16 to dependencies.
error: failed to select a version for `indexmap`.
... required by package `pyo3 v0.17.3`
... which satisfies dependency `pyo3 = "^0.17.3"` of package `pyo3-indexmap v0.1.0 (/home/dn/repos/pyo3-indexmap)`
versions that meet the requirements `>=1.6, <1.8` are: 1.7.0, 1.6.2, 1.6.1, 1.6.0
all possible versions conflict with previously selected packages.
previously selected package `indexmap v1.9.0`
... which satisfies dependency `indexmap = "^1.9"` of package `serde_yaml v0.9.16`
... which satisfies dependency `serde_yaml = "^0.9.16"` of package `pyo3-indexmap v0.1.0 (/home/dn/repos/pyo3-indexmap)`
failed to select a version for `indexmap` which could resolve this conflict
```
Couldn't find a specific reason for this limitation so I tried upgrading the dependency and running the tests.
Ran the tests locally with `indexmap==v1.9.2`:
```
❯ cargo test --features indexmap conversions::indexmap
...
running 4 tests
test conversions::indexmap::test_indexmap::test_indexmap_indexmap_insertion_order_round_trip ... ok
test conversions::indexmap::test_indexmap::test_indexmap_indexmap_to_python ... ok
test conversions::indexmap::test_indexmap::test_indexmap_indexmap_into_python ... ok
test conversions::indexmap::test_indexmap::test_indexmap_indexmap_into_dict ... ok
test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured; 536 filtered out; finished in 0.03s
```
(Tried running `cargo xtask ci` but it failed on some warnings in the generated FFI code)
This relaxes the restrictions on `indexmap` so that the latest version is also supported,
hope that's okay.
Cheers,
Gilad
Co-authored-by: Gilad Naaman <gnaaman@drivenets.com>
Sunyeop Lee