How do we gracefully handle an error during Rust->Python type conversion?

[warpedgeoid]

I'm having an issue getting a NaiveDate/NaiveDateTime converted to a Python type. I'm porting an internal library for type conversion and schema analysis of text files from pure Python to Rust + pyo3, and the performance improvement is between 15-20X in most cases. However, when dealing with dates, I'm running into an issue where some values are out of range. I guess the conversion is attempted regardless, as the code panics and we get the dreaded PanicException bubbling up in Python:

thread '<unnamed>' panicked at /Users/howardro/.cargo/registry/src/index.crates.io-6f17d22bba15001f/pyo3-0.20.0/src/conversions/chrono.rs:159:14:
failed to construct datetime: PyErr { type: <class 'ValueError'>, value: ValueError('year 0 is out of range'), traceback: None }
stack backtrace:

Does anyone know how I can handle this on the Rust side? I'm new to pyo3 and don't see that methods in ToPyObject or IntoPy return anything other than a PyObject. Not result types are used.

edit: I should add, we have considered validating the ranges before attempting a conversion, but not sure we could handle all of the edge cases properly.

[davidhewitt]

Hi, sorry you've hit a painful edge case here. We have a longstanding issue in #1813 but we need to refactor our traits to make sense of this because having ToPyObject and IntoPy is already confusing, having fallible versions of both for a total of 4 traits seems like too much. Unfortunately it is outside of my capacity to propose a solution right now, but this definitely needs fixing in the mid to long term. Help is also welcome.

What you can do is use the python datetime constructors to create the python objects in your own code and handle errors there.

[warpedgeoid]

Thanks, @davidhewitt! Due to the nature of the library, I already had a wrapper struct with three fields—one each for an optional time, date and datetime—so worked around by adding range validation to the implementation of ToPyObject for the struct. It's not pretty, but it stops the crash from happening.