Simplify IntoInitializer

[davidhewitt]

I really like the design of PyClassInitializer proposed in PyO3#683.

However, in the form proposed, I think IntoInitializer is doing too much. It's handling both what is allowed to return from #[new] as well as allowing those types to be optionally wrapped in PyResult.

This means that the use of IntoInitializer in Py<T>::new can also accept PyResult<T> as the input, which seems too generous to me. e.g. this will compile: Py::new(py, Ok(42))

This also leads to other strange API usages such as

PyResult::<i32>::Err(...).into_initializer()

I propose to simplify IntoInitializer to keep the conversion space smaller:

• Take the error handling out of IntoInitializer
• Re-use Into as much as possible
• Add a new derive_utils trait IntoPyNewResult to deal with the optional wrapping in PyResult for the macro code.

With these changes, all functionality for #[new] remains intact. The coupling between IntoInitializer and PyResult would be removed, making the API neater.

[kngwyu]

I agree that Py doesn't need to handle Result, but I have a mixed feeling for this change.

The main drawback of this change is #[new] becomes more complex. Just 1 trait is easier to understand.
I don't think this drawback is not so important.
But I think the API of Py::new is not so important, too.
It rarely appears in extension codes and actually I've never used it in my own project...

[davidhewitt]

The main drawback of this change is #[new] becomes more complex.

Respectfully I disagree with this. IntoInitializer remains the public API pyo3 users need to understand for #[new], and this PR makes it simpler.

Sure, there may be one new trait IntoPyNewResult, but it is purely a codegen implementation detail that users will never need to know about.

[kngwyu]

I understand, thank you!