[Python-Dev] Re: Rich comparisons (original) (raw)
Edward Loper edloper at gradient.cis.upenn.edu
Tue Mar 30 09:51:40 EST 2004
- Previous message: [Python-Dev] PEP 318: Set attribs with .name = value
- Next message: [Python-Dev] Re: Rich comparisons
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Edward Loper <edloper at gradient.cis.upenn.edu> writes:
This means that 'nan' is no longer a well-behaved dictionary key:
>>> x = {float('nan'):0} >>> x[float('nan')] = 1 >>> print x {nan: 0, nan: 1} Even worse, we get different behavior if we use the "same copy" of nan: >>> nan = float('nan') >>> x = {nan:0} >>> x[nan] = 1 >>> print x {nan: 1} Gah. Still, I think this is more a theoretical objection than anything else? [...] I have at no point claimed that I have given Python 2.4 a coherent ieee 754 floating point story. All I have tried to do is /reduce/ the level of surprise knocking around, and I think I've succeeded. If someone (not me!) has the time and energy to do a 'proper job' (and I'd expect working out what that means to be the hard part), then you have my support and pre-emptive thanks.
Tim Delaney's suggestion [1] seemed pretty reasonable. In particular:
- Ensure that NaN is a singleton (like True and False). I.e., the float constructor checks if the float is NaN, and if so returns a singleton.
Advantages:
- We have an easy way to test if a variable is nan: "x is NaN"
- nan will work "properly" as a dictionary key
The important question is whether this would slow down other operations. As for cmp(), my understanding was that it should just return -1 if two unordered objects are not equal.
-Edward
[1] http://aspn.activestate.com/ASPN/Mail/Message/python-dev/2030764
- Previous message: [Python-Dev] PEP 318: Set attribs with .name = value
- Next message: [Python-Dev] Re: Rich comparisons
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]