2939: Disable default features of `chrono` r=adamreichold a=messense
To avoid bringing `time` v0.1.x into dependency graph, see https://github.com/time-rs/time/issues/293
Co-authored-by: messense <messense@icloud.com>
2938: release notes for 0.18.1 r=davidhewitt a=davidhewitt
Update for `main` following release of new patch release.
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>
2937: link against pythonXY_d.dll for debug Python on Windows r=davidhewitt a=davidhewitt
Closes#2780
Note that upstream Python issue https://github.com/python/cpython/issues/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>
2936: bump maturin version in getting_started.md r=messense a=jmhodges
Latest maturin is 0.14.x, so reference that in the docs
Co-authored-by: Jeff Hodges <jeff@somethingsimilar.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>
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>
