David Hewitt
David Hewitt
Revisiting this one, I realise another downside (IMO) of the type spread is that not so `&Bound
Reading this, I also think the general mechanism `#[pyo3(warn)]` seems like the right choice. Probably the `category` should be a path to a Rust type, i.e. `#[pyo3(warn(message = "msg", category...
> Maybe we want to add a shortcut like `#[pyo3(deprecated = "msg")]` that would match `#[pyo3(warn(message = "msg", category = "DeprecationWarning"))]`? Personally I'd want this shorthand to just be the...
That makes sense. I still think that most commonly users will want to deprecate both sides at the same time and so tying both together with Rust's `#[deprecated]` is convenient...
For sake of merging this before #5107, I'll push a fix for the ui tests now.
... actually I'm not able to do so (looks like permissions have not been given for maintainers to push to the branch).
> Accepting only complex numbers with a zero imaginary part: this is what I imagine coercion to be like for complex numbers I agree fully with this. `numpy` raises a...
Will close for now, I might come back to this in the future.
This is a great question. The `clone_ref` function you propose seems relatively fine to add, to me. A related question is what to do about `GILOnceCell` in its entirety when...
I think for `py-clone` you can get a long way by replacing `PyObject` with `Arc>`, as that gives you the clone-without-the-GIL back. Maybe this should be in the migration guide...