Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Impl partialeq for pylong #4317

Merged
merged 10 commits into from
Jul 27, 2024

Conversation

WilliamTakeshi
Copy link
Contributor

@WilliamTakeshi WilliamTakeshi commented Jul 7, 2024

Thanks for the great work on PyO3!

This PR implements PartialEq for PyLong with u8, u16, u32, u64, u128, usize, i8, i16, i32, i64, i128 and isize. See #4250

As this is my first contribution to the project, I welcome any feedback or suggestions.

Copy link
Member

@mejrs mejrs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR.

However I identify a couple of problems with it. You aren't handling overflow anywhere, which means unequal values can compare equal if overflow (on either side) occurs.

I think it would be better to just extract the PyLong to the compared-to integer type and compare that, rather than casting to c_long.

Finally, you can simplify this with a macro. For example:

macro_rules! int_compare {
    ($rust_type: ty) => {
        impl PartialEq<Bound<'_, PyLong>> for $rust_type {
            #[inline]
            fn eq(&self, other: &Bound<'_, PyLong>) -> bool {
                todo!()
            }
        }
    };
}

int_compare!(i8);
int_compare!(u8);
int_compare!(i16);
//etc

src/types/num.rs Outdated Show resolved Hide resolved
src/types/num.rs Outdated Show resolved Hide resolved
src/types/num.rs Outdated Show resolved Hide resolved
Copy link
Member

@davidhewitt davidhewitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, new implementation looks great. Just one further suggestion from me

src/types/num.rs Show resolved Hide resolved
WilliamTakeshi and others added 3 commits July 11, 2024 09:25
Co-authored-by: David Hewitt <mail@davidhewitt.dev>
@@ -224,7 +224,7 @@ macro_rules! test_case {
let struct_obj = struct_class.call0().unwrap();
assert!(struct_obj.setattr($renamed_field_name, 2).is_ok());
let attr = struct_obj.getattr($renamed_field_name).unwrap();
assert_eq!(2, attr.extract().unwrap());
assert_eq!(2, attr.extract::<u8>().unwrap());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So just completing my read of the full diff, this is interesting.

What I see here is that the introduction of these implementations has changed type inference here. It's a potentially breaking change.

Is it a problem? I don't think so; user code could already define other types implementing FromPyObject and PartialEq<u8> and thus have the same inference failure.

And I believe that this new PartialEq implementation here still holds potential convenience and usability improvements.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see how this can be a breaking change. However, I don't think it's a major issue.

Ultimately, I'll leave the final decision to the maintainers haha 😃 .

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, I think we move ahead with this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't consider inference failures like this as breaking changes, so I'm also fine with this.

Copy link
Member

@davidhewitt davidhewitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, thanks for this!

@davidhewitt
Copy link
Member

I fixed the merge conflict and will proceed to merge, thanks again!

@davidhewitt davidhewitt enabled auto-merge July 26, 2024 21:20
@davidhewitt davidhewitt added this pull request to the merge queue Jul 27, 2024
Merged via the queue into PyO3:main with commit 6970cf5 Jul 27, 2024
42 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants