🤖 New build scheduled with the buildbot fleet by@rhettinger for commit056a4f7 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

🤖 New build scheduled with the buildbot fleet by@rhettinger for commit9f3f9e9 🤖

If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again.

Is my understanding right, that this PR would break the following code:

import mathclass A:    def __init__(self, a):        self.a=a    def __hash__(self):        return hash(self.a)    def __eq__(self, other):        if(math.isnan(self.a) and math.isnan(other.a)):            return True        return self.a == other.a    def __repr__(self):        return str(self.a)        set([A(float("nan")), A(float("nan"))])  # result: {nan}

I.e. when somebody tries to wrap Float and change__eq__ in such a way, that all float-nans will be equivalent?

With this PR, the chances are high, that the result will be{nan, nan}, as hashes from both objects will be different.

Until now, it was clear - don't put nans into set/dict because the default "="-relation for floats isn't an equivalence relation. People worked around this by redefining the "="-relation and didn't so for hash function because until now "a,b - nans => hash(a)=hash(b)" was given.

I think the intuitive behavior forset([float("nan"), float("nan")] is{nan} and not{nan, nan}. Given howPy_EQ is defined for floats, this is not possible. Maybe there is need for a newPy_EQ_FOR_HASH comparator, which would be used in hashset/hashdict and be more or less the same asPy_EQ but would yield true fornan==nan.