Case for REQUIRED_ARGUMENT_AFTER_OPTION

[ritchie46]

Hi, while upgrading to 0.18 in polars, I saw this warning:

use of deprecated constant `pyo3::impl_::deprecations::REQUIRED_ARGUMENT_AFTER_OPTION`: required arguments after an `Option<_>` argument are ambiguous and being phased out
         = help: add a `#[pyo3(signature)]` annotation on this function to unambiguously specify the default values for all optional parameters

We have a lot of types in polars where an optional None | int value is valid. There are passed to pyo3 as None in such a case.

We don't use it as non-required argument. Could there be a case where the type Option<T> is still allowed, but it does not mean that the argument can be elided?

Maybe a required_all proc macro?

[adamreichold]

@ritchie46 Could you please also paste the full signature of such a #[pyfunction] here so hat this easier to understand. Thanks!

[birkenfeld]

Could there be a case where the type Option is still allowed, but it does not mean that the argument can be elided?

Isn't that the behavior you get when you put the argument into signature without a default value?

I.e. the two cases are

#[pyo3(signature=(a, b))]
fn do(a: u64, b: Option<u64>) {}  // b can be None but must be given from Python

vs

#[pyo3(signature=(a, b=None))]
fn do(a: u64, b: Option<u64>) {}  // b can be omitted from Python

Both cases are still supported, PyO3 just now wants the signature annotation to disambiguate.

[ritchie46]

Right, I realized later. Maybe defaulting to the any of the two (I oreythw first) might save some proc macro headers.

In any case, that's only ergonomics.

Thanks for the clarification.

[davidhewitt]

For what it's worth, #2934 may help document this for future readers.