Allow other Result types in #[pyfunction] etc

[davidhewitt]

At the moment the only Result type we allow in #[pyfunction] is PyResult.

After a question on Gitter yesterday I was thinking if we can allow instead any Result which has E: Into<PyErr>.

That would allow code like this (all implementations replaced with ...):

enum MyError { ... }

impl From<MyError> for PyErr { ... }

#[pyfunction]
fn my_err_function() -> Result<(), MyErr> { ... }

Pros:

• Extra flexibility for users implementing #[pyfunction]
• Error handling improvement when calling this #[pyfunction] in Rust - can handle MyError typed enum rather than dynamic PyErr.
• Possible performance improvement when calling this #[pyfunction] in Rust - no need to create PyErr which is relatively higher-cost than MyError.

Cons:

• Making this accept more types might over-complicate pyo3's API. I'm not sure it's so bad, though.

cc @marioortizmanero who posted on this topic on Gitter. (At least, I think that was what was being asked!)

[davidhewitt]

Broadly speaking, I don't think the implementation is too hard. I think we can just replace these lines in callback.rs:

pyo3/src/callback.rs

Lines 40 to 47 in 4840619

	impl<T, U> IntoPyCallbackOutput<U> for PyResult<T>
	where
	T: IntoPyCallbackOutput<U>,
	{
	fn convert(self, py: Python) -> PyResult<U> {
	self.and_then(|t| t.convert(py))
	}
	}

with this implementation:

impl<T, E, U> IntoPyCallbackOutput<U> for Result<T, E>
where
    T: IntoPyCallbackOutput<U>,
    E: Into<PyErr>
{
    fn convert(self, py: Python) -> PyResult<U> {
        self.map_err(Into::into).and_then(|t| t.convert(py))
    }
}

However, at the moment this causes pyo3 to fail to compile because type inference for the new parameter E is not possible. I think this type inference failure only applies to some internal implementations of our #[pyproto], and for external code this would not be a problem (because in #[pyfunction] the return type is always specified, so no type inference applies).

So our internal code would need a little refactoring, but otherwise it's reasonably straightforward.

[birkenfeld]

Note that the question mark operator already calls into() so I don't think the flexibility implementing the pyfunction is really needed. The other pros might be nice though.

[marioortizmanero]

I'm the one who suggested this feature, and yes, you got it right.

I think that as long as it's well documented, it shouldn't be an issue. This should be mentioned in the type conversions table of the book with a note that the wrapped Error must implement E: Into<PyErr>, and maybe even in the exceptions section of the book as well.

I could implement this myself but I'm very new to pyo3 so I would need a bit of hand holding. Not sure if I should.

[davidhewitt]

@marioortizmanero if you're interested in implementing this then you're very welcome to provide a PR! I'm happy to review or answer any questions you have.

[marioortizmanero]

Thanks @davidhewitt, I've opened a new PR at #1118 with the proposed changes. Please take a look and let me know.

[marioortizmanero]

This can be closed now as #1118 was merged, @davidhewitt

[davidhewitt]

Thanks 👍