release: 0.18.1 #2928
Merged
release: 0.18.1 #2928
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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>
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>
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>
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>
Closes #2915 When using the C API directly, the intended way to call `visitproc` is via the `Py_VISIT` macro, which checks to see that the provided pointer is not null before passing it along to `visitproc`. Because PyO3 isn't using the macro, it needs to manually check that the pointer isn't null. Without this check, calling `visit.call(&obj)` where `let obj = None;` will segfault.
Since we're just testing a bug during traversal, we don't actually have to reap the object, we just have to make a reference cycle so that it's traverse method is called.
2911: add `Ellipsis()` and `is_ellipsis()` methods r=mejrs,davidhewitt a=samuelcolvin fix #2906 Please consider adding the following to your pull request: - [x] an entry for this PR in newsfragments - see [https://pyo3.rs/main/contributing.html#documenting-changes] - [x] docs to all new functions and / or detail in the guide - [x] tests for all new or changed functions Co-authored-by: Samuel Colvin <s@muelcolvin.com>
2904: refactor docstring generation code r=mejrs a=davidhewitt As a first step towards #2866 this is a tweak to the macro code which generates Python docstrings. This PR refactors the behaviour so that instead of always creating a `concat!` expression to generate a nul-terminated string, this will only happen if a Rust 1.54+ macro doc is present (e.g. `#[doc = include_str!(...)]`). The default case now just collects all the `#[doc]` attributes into a single string. This should make it easier to factor out the `text_signature` formatting, and avoids wasting compile time invoking the `concat!` macro when not necessary. 2921: Check to see if object is `None` before traversing r=davidhewitt a=neachdainn Closes #2915 When using the C API directly, the intended way to call `visitproc` is via the `Py_VISIT` macro, which checks to see that the provided pointer is not null before passing it along to `visitproc`. Because PyO3 isn't using the macro, it needs to manually check that the pointer isn't null. Without this check, calling `visit.call(&obj)` where `let obj = None;` will segfault. Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com> Co-authored-by: Nate Kent <nate@nkent.net>
…to a Rust app while having option to test API without the main app
2923: hygiene: fix `#[pymethods(crate = "...")]` r=davidhewitt a=davidhewitt Got to the bottom of the hygiene issue in test of #2914 Turns out that `#[pymethods] #[pyo3(crate = "...")]` works, but `#[pymethods(crate = "...")]` was ignoring the argument. Added a tweak to fix this and a snippet in the hygiene test (which fails on `main`). 2924: remove unneeded into_iter calls r=davidhewitt a=davidhewitt Clippy complaining about these to me this morning locally. Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2873: A new example that shows how to integrate Python plugins that use pyclasses into a Rust app r=davidhewitt a=alexpyattaev
Example showing integration of a Python plugin into a Rust app while having option to test pyclass based API without the main app. This also illustrates some aspects related to import of Python modules into a Rust app while also having an API module available for the Python code to be able to produce Rust objects.
CI seems to fail on my local machine for reasons unrelated to the example just added:
```
error: unused macro definition: `check_struct`
--> pyo3-ffi-check/src/main.rs:13:18
|
13 | macro_rules! check_struct {
| ^^^^^^^^^^^^
|
```
Co-authored-by: Alex Pyattaev <alex.pyattaev@gmail.com>
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
|
Thanks @davidhewitt. #2912 should be complete, but TBH I'm not that bothered about including it, I can easily use the methods via #2914 is another matter - it would be great to get this included! I currently have numerous |
2912: Add `PyDict.update()` and `PyDict.update_if_missing()` r=davidhewitt a=samuelcolvin Fix #2910 Note, I'd also be happy to remove the `override_` argument from merge and perhaps rename it to `update_missing` or similar to give a cleaner API. LMK what you think. Please consider adding the following to your pull request: - [x] an entry for this PR in newsfragments - [x] docs to all new functions and / or detail in the guide - [x] tests for all new or changed functions Co-authored-by: Samuel Colvin <s@muelcolvin.com>
|
Sorry for the delay, family ill again, obviously Tuesday has flown past. I'll get rebasing this and I think #2914 needs to be included before we push, as there's a nasty bug there. |
|
No problem, I know all about missing self imposed deadlines. |
davidhewitt
force-pushed
the
release-0.18.1
branch
2 times, most recently
from
f2ade04
to
184c085
Compare
2933: changelog: add missing entry for frozen r=davidhewitt a=davidhewitt After discussion in PyO3/rust-numpy#367 (comment) I noticed we were missing a CHANGELOG entry for frozen. This doesn't help past users but does help document when the feature was released (in 0.17.0). Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2930: add better error message for Python in signature r=adamreichold a=davidhewitt Inspired by #2929, this just adds a better error message when `Python` arguments are accidentally included in the signature. Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2914: correct ffi definition of PyIter_Check r=davidhewitt a=davidhewitt Closes #2913 It looks like what is happening is that PyO3 was relying on an outdated macro form of `PyIter_Check` which is now a CPython implementation detail, which would explain why it was behaving inconsistently on different platforms (likely due to differences in linkers / implementations). The test I've pushed succeeds, but fails to compile due to a hygiene bug! I'm done for tonight so I'll take a look at that soon and then rebase this after. Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2929: docs: Precise the abscense of `py: Python` for the #[pyo3(signature)] r=davidhewitt a=jjerphan Hi, First, thank you for working on PyO3! I think this adds a precision which was not obvious when migrating to 0.18.0 conventions. What do you think? Also, should something be added to [the migration guide](https://pyo3.rs/main/migration) in this regard? Thank you! Co-authored-by: Julien Jerphanion <git@jjerphan.xyz>
Latest maturin is 0.14.x
2937: link against pythonXY_d.dll for debug Python on Windows r=davidhewitt a=davidhewitt Closes #2780 Note that upstream Python issue python/cpython#101614 means linking against `python3_d.dll` is useless, so I've set this to always use the version-specific builds for now. The heuristic for detecting a Windows debug build is... not great. I check if the `EXT_SUFFIX` starts with `_d.`, which is the only thing that I could see in the sysconfig which suggested a debug build. If this proves to be brittle, we may wish to ask upstream for something better to be added to `sysconfig`. Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2934: guide: add documentation for trailing option arguments r=davidhewitt a=davidhewitt Following the increased clarity around PyO3's handling of function signatures of 0.18.0, I wanted to add a section to the guide documenting the default-to-none behaviour for trailing `Option<T>` arguments. Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
davidhewitt
force-pushed
the
release-0.18.1
branch
from
184c085
to
37d377e
Compare
|
Release is live! |
|
Amazing, thank you. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We've collected a few useful fixes and additions since 0.18.0 was pushed live, so I suggest we cut a new release.
I've arbitrarily picked Tuesday to find a moment to push this.
@samuelcolvin if you'd like to have #2912 in the release then let me know before Tuesday, we can wait a bit for that PR to be finished off first.