-
Notifications
You must be signed in to change notification settings - Fork 779
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
Impl partialeq for pylong #4317
Conversation
There was a problem hiding this 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
There was a problem hiding this 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
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()); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 😃 .
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this 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!
I fixed the merge conflict and will proceed to merge, thanks again! |
Thanks for the great work on PyO3!
This PR implements
PartialEq
forPyLong
withu8
,u16
,u32
,u64
,u128
,usize
,i8
,i16
,i32
,i64
,i128
andisize
. See #4250As this is my first contribution to the project, I welcome any feedback or suggestions.