Larry Z.

Thanks for the direction! I'll take a look :)

It looks like the arguments are passed to `maturin` and then to `cargo` during building `rpds`. See [here](https://doc.rust-lang.org/cargo/reference/profiles.html#dev) and [here](https://www.maturin.rs/local_development). The dev profile enables the overflow check and that's why...

Yes I think `test` would make more sense. I can modify the CI to do that :)

Thanks for catching that! I was not aware of overflowing in Rust when implementing it. I'll submit a PR to fix it soon!

Thanks for the detailed feedback! I'll work on these points!! :) Regarding documenting this attribute for `#[pymethods]`, I remember the document refers back to `#[pyfunction]`'s options, so maybe putting it...

> * Reading this, it feels like this is really just a general mechanism for raising warnings, not necessarily deprecation warnings. Should we maybe just call it pyo3(warn)? 🤔 The...

That sounds good! I will refactor the current one to `warn` and make a new `deprecated` to be a shortcut of `DeprecationWarning` :)

> 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 the...

Hi all! The `#[pyo3(warn(message = "...", category = ...))]` and `#[pyo3(deprecated = "...")]` should have been implemented properly. The `warn` attribute now behaves like the `warnings.warn` and emits `UserWarning` when...

> I saw that you opened this to support multiple warnings. I currently don't see a big problem with that. It _does_ however interact with automatic Rust deprecation since we...