Mark Dickinson <[email protected]> added the comment:
@realead
> This change makes life harder for people trying to get sane behavior with
> sets [...]
Yes, code that assumes that all NaNs have the same hash value will need to
change. But that doesn't seem unreasonable for objects that are already
considered distinct with respect to the containment equivalence relation ("is"
followed by "=="). I think this change was the right one to make, and my
expectation was that there would be few cases of breakage, and that for those
few cases it shouldn't be difficult to fix the breakage. If that's not true
(either there are lots of cases of breakage, or the breakage is hard to fix),
perhaps we should reconsider. I haven't yet seen evidence that either of those
things is true, though.
> Maybe a new comparator is called for [...]
Agreed that that seems like a possible technical solution: Python could add a
new special method __container_eq__ which is required to provide (at the least)
a reflexive and symmetric relation, and whose default implementation does the
same is-followed-by-== check that's already used for list, dict and set
containment. For what it's worth, this is close to the approach that Julia
takes: they have an "is_equal" function that's mostly the same as the normal
equality == but differs for NaNs (and incidentally for signed zeros). But
whether this would make sense from a language design perspective is another
matter, and it would be a significant language-level change (certainly
requiring a PEP). It feels like an enormous conceptual change to introduce to
the language just to deal with the annoyance of NaNs. And that really is all it
would be good for, unless perhaps it also provides a solution to the problem of
NumPy arrays in containers, again caused by NumPy arrays overriding __eq__ in a
nonstandard way.
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue43475>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
