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>
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>
2933: changelog: add missing entry for frozen r=davidhewitt a=davidhewitt
After discussion in https://github.com/PyO3/rust-numpy/pull/367#issuecomment-1409283700 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>
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>
2926: Warn about unknown config keys in `PYO3_CONFIG_FILE` r=davidhewitt a=messense
`maturin` also read from `PYO3_CONFIG_FILE` to get `ext_suffix` config, `pyo3-build-config` currently denies unknown config keys makes it inconvenient.
See https://github.com/PyO3/maturin/issues/1430
Co-authored-by: messense <messense@icloud.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>
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>
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>
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>
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.
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.
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>
