2899: RFC: Provide a special purpose FromPyObject impl for byte slices r=davidhewitt a=adamreichold
This enables efficiently and safely getting a byte slice from either bytes or byte arrays.
The main issue I see here is discoverability, i.e. should this be mention in the docs of `PyBytes` and `PyByteArray` or in the guide?
It is also not completely clear whether this really _fixes_ the issue.
Closes#2888
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
2979: allow `create_exception!` to place the exception in a `dotted.module` r=adamreichold a=davidhewitt
Closes#2946
Credit fully to `@BlueGlassBlock`
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2974: Reduce API surface of mod gil to better encapsulate its safety invariants. r=davidhewitt a=adamreichold
Closes#2969
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
2976: Update Example projects r=adamreichold a=kngwyu
Interestingly, it may be used for ChatGPT 😅
Also I removed my old project because it's way too outdated (around pyo3 0.10?)
Co-authored-by: Yuji Kanagawa <yuji.kngw.80s.revive@gmail.com>
2952: Fix allow_threads segfault r=davidhewitt a=OliverBalfour
Please see the corresponding issue **#2951** for details. This PR adds the failing test from the issue and then a fix for it. The fix simply calls `ReferencePool::update_counts` at the end of `allow_threads` to ensure objects aren't accidentally deleted too soon.
Co-authored-by: Oliver Balfour <oliver.leo.balfour@gmail.com>
2964: Update `README.md` by adding datafusion, ballista and delta-rs r=adamreichold a=iajoiner
Add Python bindings of datafusion, ballista and the official Rust implementation of Delta Lake (delta-rs). The former two are Apache projects under Arrow and the last is from Delta Lake itself so all three projects are notable and need to be added as examples.
Co-authored-by: Ian Alexander Joiner <14581281+iajoiner@users.noreply.github.com>
2961: docs: fix typo in method name r=adamreichold a=lycantropos
There's no `PyFunction::new_closure`, but there is [`PyCFunction::new_closure`](3b2c175f8d/src/types/function.rs (L50-L104)), so I guess it's a typo in docs.
Co-authored-by: Azat Ibrakov <azatibrakov@gmail.com>
2947: change PyModule::add_class to return an error if class creation fails r=adamreichold a=davidhewitt
Related to #2942
At the moment there are panics deep in the `#[pyclass]` machinery when initialising the type fails. This PR adjusts a number of these functions to return `PyResult` instead, so that we can handle the error more appropriately further down the pipeline.
For example, take the following snippet:
```rust
#[pyclass(extends = PyBool)]
struct ExtendsBool;
#[pymodule]
fn pyo3_scratch(_py: Python, m: &PyModule) -> PyResult<()> {
m.add_class::<ExtendsBool>()?;
Ok(())
}
```
Currently, importing this module will fail with a panic:
```
TypeError: type 'bool' is not an acceptable base type
thread '<unnamed>' panicked at 'An error occurred while initializing class ExtendsBool', /Users/david/Dev/pyo3/src/pyclass.rs:412:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/Users/david/.virtualenvs/pyo3/lib/python3.10/site-packages/pyo3_scratch/__init__.py", line 1, in <module>
from .pyo3_scratch import *
pyo3_runtime.PanicException: An error occurred while initializing class ExtendsBool
```
After this PR, this import still fails, but with a slightly cleaner, more Pythonic error:
```
TypeError: type 'bool' is not an acceptable base type
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/Users/david/.virtualenvs/pyo3/lib/python3.10/site-packages/pyo3_scratch/__init__.py", line 1, in <module>
from .pyo3_scratch import *
RuntimeError: An error occurred while initializing class ExtendsBool
```
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
2944: optimize sequence conversion for list and tuple r=adamreichold a=davidhewitt
closes#2943
Avoid using `PyObject_IsInstance` for checking if lists or tuples are sequences, as we know they are always sequences.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2954: optimize mapping conversion for dict r=davidhewitt a=davidhewitt
Equivalent of #2944 for dicts -> mapping.
The benchmark diff is not as significant as in #2944. Still something like 80ns -> 2ns on my machine.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2955: add pydantic's use of Rust to README r=davidhewitt a=davidhewitt
Adding links to Pydantic to PyO3's readme - if you're ok with this `@samuelcolvin` ? :)
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2953: set csv minimal package version for 1.48 CI r=davidhewitt a=davidhewitt
New `csv 1.2.0` requires Rust 1.60.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2948: don't parse doc attributes unnecessarily r=davidhewitt a=davidhewitt
While working on #2866 I found that for all `#[pymethods]` we process the `#[doc]` attributes and build a Python docstring. However we don't always emit this doc - e.g. for class attributes and `__dunder__` methods.
This is just a small adjustment to move the `#[doc]` processing slightly later in the macro code to avoid the wasted work. (It also helps for the #2866 implementation later.)
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2945: move some private internals out of public implementation r=davidhewitt a=davidhewitt
This runs some quick cleanups on private stuff:
- Remove `#[doc(hidden)]` trait `TryFromPyCell` which is unused.
- Move `#[doc(hidden)]` struct `pyo3::type_object::LazyStaticType` to `pyo3::impl_::pyclass::LazyStaticType`.
- Move `pub(crate)` function `pyo3::pyclass::create_type_object` into submodule, to clean up main `pyclass.rs` implementation for readers.
As this is no behaviour change and separates stuff out slightly better, I'm just going to proceed to merge this. If anyone reading this wants to suggest a different way to factor out, happy to write a follow-up PR.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
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>
