On Thu, Apr 28, 2011 at 4:40 PM, Nick Coghlan
Pondering the NaN problem further, I think we can relatively easily argue that reflexive behaviour at the object level fits within the scope of IEEE754.
Now we're talking. :-)
1. IEEE754 is a value-based system, with a finite number of distinct NaN payloads 2. Python is an object-based system. In addition to their payload, NaN objects are further distinguished by their identity (infinite in theory, in practice limited by available memory). 3. We can still technically be conformant with IEEE754 even if we say that a given NaN object is equivalent to itself, but not to other NaN objects with the same payload.
Unfortunately, this still doesn't play well with serialisation, which assumes that the identity of float objects doesn't matter:
import pickle nan = float('nan') x = [nan, nan] x[0] is x[1] True y = pickle.loads(pickle.dumps(x)) y [nan, nan] y[0] is y[1] False
Contrast that with the handling of lists, where identity is known to be significant:
x = [[]]*2 x[0] is x[1] True y = pickle.loads(pickle.dumps(x)) y [[], []] y[0] is y[1] True
Probably wouldn't kill us if fixed pickle to take object identity into account for floats whose value is nan. (Fortunately for 3rd party types pickle always preserves identity.)
I'd say I've definitely come around to being +0 on the idea of making the float() and decimal.Decimal() __eq__ definitions reflexive, but doing so does have implications when it comes to the ability to accurately save and restore application state. It isn't as simple as just adding "if self is other: return True" to the respective __eq__ implementations.
But it seems pickle is *already* broken, so that can't really be an argument against the proposed change, right? -- --Guido van Rossum (python.org/~guido)