On Sun, 29 May 2011 18:44:08 +0100, MRAB wrote: > Would there be any advantage to making NaN a singleton?
Absolutely not. That would be a step backwards. NANs can carry payload (a code indicating what sort of NAN it represents -- log(-1) and 1/INF are not the same). So although Python currently has no easy way to access that payload (you can do it with the struct module), it does exist and for serious work you would want to be able to set and get it. > I'm thinking > that it could make checking for it cheaper in the implementation of sets > and dicts. I don't see how would it be cheaper, but even if it were, talk about a micro-optimization! I'd really *love* to see the code where the time it takes to insert a NAN in a set was the bottleneck! > Or making NaN unhashable? I could live with that, although I don't think it is necessary. What actual problem are you hoping to solve here? -- Steven -- http://mail.python.org/mailman/listinfo/python-list