float("nan") in set or as key

Steven D'Aprano steve+comp.lang.python at pearwood.info
Mon May 30 19:22:01 EDT 2011


On Mon, 30 May 2011 19:58:35 +0000, Chris Torek wrote:

> In article <4de3358b$0$29990$c3e8da3$5496439d at news.astraweb.com> Steven
> D'Aprano  <steve+comp.lang.python at pearwood.info> wrote:
>>Better than a float method is a function which takes any number as
>>argument:
>>
>>>>> import math, fractions, decimal
>>>>> math.isnan(fractions.Fraction(2, 3))
>>False
>>>>> math.isnan(decimal.Decimal('nan'))
>>True
> 
> Ah, apparently someone's been using Larry Wall's time machine. :-)

He has one too? Just like Guido van Rossum.

 
> I should have looked at documentation.  In my case, though:
> 
>     $ python
>     Python 2.5.1 (r251:54863, Dec 16 2010, 14:12:43) [GCC 4.0.1 (Apple
>     Inc. build 5465)] on darwin Type "help", "copyright", "credits" or
>     "license" for more information.


Python 2.5 is two major releases behind! I feel your pain, though, 
because 2.5 is the system python on my desktop as well. (And 2.4 is the 
system python on my server, ouch!)

You should consider installing 2.7 and/or 3.2 in parallel with the system 
python.


> Would it be appropriate to have isnan() methods for Fraction, Decimal,
> and complex, so that you do not need to worry about whether to use
> math.isnan() vs cmath.isnan()?

Probably not. From a purely object-oriented, Java-esque viewpoint, yes, 
all number types should support isnan and isinf methods, but Python uses 
a more mixed style, and a function that accepts multiple types is 
appropriate.

Unless you're using complex numbers, you don't need to care about complex 
numbers. *wink* Hence for "normal" numeric use, stick to the math module. 
If you do need complex numbers, cmath.isnan works perfectly fine with non-
complex arguments:

>>> cmath.isnan(42)
False
>>> cmath.isnan(float('nan'))
True


-- 
Steven



More information about the Python-list mailing list