You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just a thought: why don't we add is_eq(), is_gt() etc methods (alongside the compare and rich_compare), for the sake of newcomer-friendliness? Sort of the same as is_none() etc.
Also, note explicitly in trait impl docstrings (and in is_eq/is_ne docstrings) that PartialEq compares pointers, which may otherwise lead to confusion.
(Here's a use case example. I've used pyo3 and rust-numpy for quite a lot and I've read large chunks of its sources but never needed to compare Python objects before for some reason. When I did, I started searching docs.rs and source code and gh repo for "eq" but was unable to find anything. It took me a good while till I randomly stumbled on rich_compare. Maybe I'm still missing something?)
The text was updated successfully, but these errors were encountered:
Just a thought: why don't we add
is_eq()
,is_gt()
etc methods (alongside thecompare
andrich_compare
), for the sake of newcomer-friendliness? Sort of the same asis_none()
etc.Also, note explicitly in trait impl docstrings (and in
is_eq
/is_ne
docstrings) thatPartialEq
compares pointers, which may otherwise lead to confusion.(Here's a use case example. I've used pyo3 and rust-numpy for quite a lot and I've read large chunks of its sources but never needed to compare Python objects before for some reason. When I did, I started searching docs.rs and source code and gh repo for "eq" but was unable to find anything. It took me a good while till I randomly stumbled on
rich_compare
. Maybe I'm still missing something?)The text was updated successfully, but these errors were encountered: