Structs without operations defined. Does Python natively attempt to force float conversion?

[attack68]

I have defined two structs in rust, which I can use in Python via #[pyclass], for minimalist example:

struct D1 {
    some_data: f64
}
struct D2 {
    some_date: f64
}

I have performed operator overloading on these for many operations for their same struct ops and crossing with f64.
I.e. in rust the following work: D1 + D1, D1 + f64, D2 + D2, D2 + f64.

In rust the following does not work D1 + D2 due to no implementation for D1 + D2. This is as designed.

In Python if I add D1 + D2 it seems to be converting one of them to float and returning a valid result.

Where is this conversion taking place and how do I avoid it?

For D1 in #[pymethods] I have defined:

#[derive(FromPyObject)]
pub enum D1OrF64 {
    D1(D1),
    F64(f64),
}

    fn __add__(&self, other: D1OrF64) -> Self {
        match other {
            D1OrF64::D1(d) => self + d,
            D1OrF64::F64(f) => self + f,
        }
    } 

I am wondering if FromPyObject is specifically converting a D2 to f64 since there is a valid __float__ pymethod available on both D1 and D2?

Is it possible to specifically prevent this? Am I wrong about the location of the conversion? Do I need to expand all of my match cases and my enum to include all 3 types: D1, D2 and f64?

[birkenfeld]

I think you'll need to provide a more complete minimal example. At the moment it's hard to follow what's happening on your end.

[attack68]

OK a playground link is here: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=13acb058ec76ae55db9b644cd2958698

You can use this to verify that the test at the bottom fails becuase this is no implementation of a struct D1 adding D2.

If you export D1 and D2 to Python with PyO3 and run in Python:

a = D1(3.0)
b = D2(2.5)
c = a + b # works in Python returns a D1.
c = b + a # works in Python returns a D2.

[birkenfeld]

Thanks! Yes, I believe you're correct that the enum extractions tries to get an f64 which triggers the __float__ defined on the D1/2 class.

[attack68]

OK but is there a sensible way in PyO3 to prevent that? I want to be able to use float(a) in Python but I don't want rust to do that with the operators.
The workaround I have is to to create an enum with f64, D1 and D2 types, but that is quite a lot of work to integrate everything.

[davidhewitt]

I think you are hoping for #3672

At the moment the closest workaround would probably be to have

#[derive(FromPyObject)]
pub enum D1OrFloat<'py> {
    D1(D1),
    Float(&'py PyFloat),
}

which will then only accept python floats for the second variant.

[attack68]

Just circling back on this @davidhewitt, is there an alternate solution which can keep the following as is (since I don't want to introduce pyo3 types to an existing library)

pub enum D1OrF64 {
    D1(D1),
    F64(f64),
}

but can implement the FromPyObject directly so that only PyFloats are captured to the F64 variant?

[davidhewitt]

I think you want something like

pub enum D1OrF64 {
    D1(D1),
    #[pyo3(from_py_with = "custom_extraction_function")]
    F64(f64),
}

where you can then implement the logic you want in the custom function.

https://pyo3.rs/v0.22.5/conversions/traits#derivefrompyobject-field-attributes