2981: Remove 0.17 deprecations r=adamreichold,davidhewitt a=davidhewitt
Since #2980 starts a breaking change for 0.19, let's also clean up all 0.17's deprecations.
I've removed `Python::acquire_gil` in its own commit, as that was a reasonably chunky removal.
Co-authored-by: Adam Reichold <adam.reichold@t-online.de>
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
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>
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>
3014: feat: add #[pyo3(get, set)] for Cell r=davidhewitt a=AntoineRR
This fixes#2659.
The types for which `#[pyo3(get, set)]` should now work are `Cell`, `Arc` and `Box`.
There is one issue regarding `Box`, the implementation of `FromPyObject` conflicts with another one. I could not find what the issue was, especially since the other implementations for `Arc` and `Cell` work as expected. The related code and test has been commented out for now. Maybe someone could help me fix this issue if I don't figure it out myself? There is also the possibility to remove the implementation for `Box` of course.
Co-authored-by: Antoine Romero-Romero <ant.romero2@orange.fr>
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>
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.
2796: Forward cfgs on pyclass fields to the method defs r=davidhewitt a=mejrs
With this and the cfg_attr PR, I don't need cfg_eval at all anymore :)
- [x] needs some more tests
Co-authored-by: mejrs <>
2739: error when `#[pyo3(signature = ())]` used on invalid methods r=davidhewitt a=davidhewitt
A follow-up to #2702 to reject some invalid applications of `#[pyo3(signature = (...))]` attribute, specifically on magic methods and getters / setters / class attributes.
Co-authored-by: David Hewitt <1939362+davidhewitt@users.noreply.github.com>
