Deserialize dataclass as Rust struct/mapping

[Kobzol]

Hi, thanks for the great crate! I'm using it to deserialize things that I can't easily wrap with #[derive(FromPyObject)], but that are serde compatible. On the Python side, I'm using dataclasses a lot, and I'd like to convert them to Rust structs. So I have something like this on the Rust side:

#[derive(serde::Deserialize)] // This can't use FromPyObject
struct Foo {
    a: i32,
}

#[pyfunction]
fn take_foo<'s>(py: Python, arg: &Bound<'s, PyAny>) {
    pythonize::depythonize::<Foo>(arg).unwrap();
} 

and I'd like to send something like this from the Python side:

@dataclasses.dataclass
class Foo:
    a: int

ffi.take_foo(Foo(a=1))

However, currently that ends with an error:

pyo3_runtime.PanicException: called `Result::unwrap()` on an `Err` value: UnexpectedType("'Foo' object cannot be converted to 'Mapping'")

Is there a way to make it work? I can pre-convert the dataclass to a dictionary with dataclasses.as_dict(Foo(a=1)), but that seems wasteful. FromPyObject is able to read the fields of the object, even if it is not a dictionary, so it seems like depythonize could also do that.

Thanks for your answer!

[davidhewitt]

Hey, thanks for the appreciation and the great question.

I chose to use mappings as the deserialize source because the serialization produces dicts, and this round-tripped cleanly. That said, I can see your use-case for this one-way conversion.

I wonder if we can implement configuration for depythonize which would allow you to override this per-type, similar to pythonize_custom.

Or is there some metadata mechanism in serde we could exploit? 🤔

[Kobzol]

I wonder if pythonize could just attempt to treat (data)classes as dicts, and use field accessors when a dict field is being deserialized, similarly to what FromPyObject does.

[davidhewitt]

Sorry for the long delay here. I think what you suggest seems reasonable, given that at present dataclasses will be rejected. We can add this as a fallback case without breaking.

[Kobzol]

I briefly took a look at it, and it looks like dataclasses and class objects end up here.

I guess that we'd have to special case this scenario - check if the passed object is a (data)class object, and then create a new implementation of de::MapAccess that will use some Python function (or __dict__?) to iterate over its fields and their values?