It might not be obvious from the reading the sections on free functions and on
classes that they combine in a frictionless manner, i.e. class instances can be
parameters to free functions in the same manner that the self parameters of
instance methods are handled.
This also explicitly calls out the interaction between `Clone` and
`FromPyObject` for classes.
3203: support ordering magic methods for `#[pyclass]` r=adamreichold a=davidhewitt
Closes#2089
This adds `__lt__`, `__le__`, `__eq__`, `__ne__`, `__gt__`, and `__ge__` as per the Python implementations of what we call `__richcmp__`.
There's a UI test confirming that the user cannot implement split forms and `__richcmp__` simultaneously.
There's also a benchmark comparing implementing these split methods against using `__richcmp__`. I couldn't see a meaningful performance difference, so I'm tempted to deprecate `__richcmp__`, given that's not a magic method which exists in Python. Potentially we can provide options such as the opt-in `#[pyclass(eq, ord)]` to avoid boilerplate for people who don't want to implement six different methods.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2593: docs: mention PyBuffer r=adamreichold a=davidhewitt
Uses PEP 688 `types.Buffer` to describe `PyBuffer<T>` in the conversion tables. Will leave as draft until PEP 688 is finalised.
Closes#954
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
2980: support `text_signature` on `#[new]` r=adamreichold a=davidhewitt
Closes#2866
This is a breaking change for 0.19.0, because it starts autogenerating `text_signature` for `#[new]`. This could affect runtime behaviour if the user is relying on the class docs at runtime for some reason.
Guide & tests all updated accordingly.
`#[pyclass(text_signature = "...")]` is deprecated by this PR, however if it's set, it will be used in preference to `#[new]`.
(The signature / `text_signature` from `#[new]` will simply be ignored in this case. I figure that when users fix their deprecation warnings by removing `#[pyclass(text_signature = "...")]` then the `#[new]` signatures will start flowing properly, and this is good enough.)
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
Implement conversion between rust_decimal::Decimal and decimal.Decimal
from Python's stdlib. The C API does not appear to be exposed on the
Python side so we need to call into it via Python.
3066: Improve default value for `None` in `text_signature` r=davidhewitt a=messense
xref #2863
3098: readme: add new pyo3 article r=adamreichold a=davidhewitt
With thanks to `@ohadravid` for the great piece!
Co-authored-by: messense <messense@icloud.com>
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
2975: RFC: Add GILProtected synchronization primitive and use it for LazyTypeObjectInner. r=davidhewitt a=adamreichold
I would also like to use that type in rust-numpy and it seems we can avoid ~~both a manual unsafe impl and~~ a full blown mutex if we apply it to `LazyTypeObjectInner`.
One downside might be that it ties us closer to the GIL when we want to enable nogil experimentation, but on the other hand, it may also help by reifying the GIL usage. (This is currently limited to comments in unsafe code in rust-numpy for example.)
3022: Fix function name shadowing r=davidhewitt a=mejrs
Fixes https://github.com/PyO3/pyo3/issues/3017
3023: Emit a better error for bad argument names r=davidhewitt a=mejrs
This will emit a better error for code like
```rust
#[pyfunction]
fn output([a,b,c]: [u8;3]) {}
```
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
Co-authored-by: mejrs <59372212+mejrs@users.noreply.github.com>
2982: explain STATUS_DLL_NOT_FOUND r=adamreichold a=mejrs
I had someone ask me this today, and googling for it I found various other places where this was asked, with no (good) answers.
Co-authored-by: mejrs <59372212+mejrs@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>
