ISTM there is no right or wrong answer. There is just a question of what is most useful.
AFAICT, the code for dictionaries (and therefore the code for sets) has always had identity-implies-equality logic. It makes dicts blindingly fast for common cases. It also confers some nice properties like making it possible to retrieve a NaN that has been stored as a key; otherwise, you could store it but not look it up, pop it, or delete it (because the equality test would always fail). The logic also confers other nice-to-have properties such as:
* d[k] = v; assert k in d # assignment-implies-contains * assert all(k in d for k in d) # all-members-are-members
These aren't essential invariants but they do provide a pleasant programming environment and make it easier to reason about programs.
Another place where identity-implies-equality logic is explicit is in Py_RichCompareBool(). That lets methods in many other functions and methods work like dicts and sets. It speeds them up and confers some nice-to-haves like:
* mylist.append(obj) implies mylist.count(obj) > 0 * x = obj implies x == obj # assignment really works
There may be lots of other code that implicitly makes similar assumptions. I don't know how you could reliably find those and rip them out.
If identity-implies-equality does get ripped out, I don't know what we would win. It would make it possible to do some cute NaN tricks, but I don't think you can defend against the general problem of funky objects being able to muck-up code that looks correct. You get oddities when an object lies about its length. You get oddities when an object has a hash that doesn't match its equality function. The situation with NaNs and sorts is a prime example:
sorted([1.2, 3.4, float('Nan'), -1.2,
float('Inf'), float('Nan')]) [1.2, 3.4, nan, -1.2, inf, nan]
Personally, I think the status quo is fine and that practicality is beating purity. High quality programs are written every day. Numeric programmers seem to have no problem using NaNs as-is. AFAICT, the only actual problem in front us is the OP's post where he was able to surprise himself with some NaN experiments at the interactive prompt.
On Fri, Apr 29, 2011 at 5:51 AM, Raymond Hettinger email@example.com wrote:
- x = obj implies x == obj # assignment really works
While I agree with your point of view regarding the status quo as a useful, practical compromise, I need to call out that particular example:
nan = float('nan') x = nan x == nan
x in locals().values()
Due to rich comparison and the freedom to implement non-reflexive definitions of "equality", the assignment "x = obj" implies only that: - x is obj - x in locals().values()