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

> In article <4de3358b$0$29990$c3e8da3$54964...@news.astraweb.com> Steven
> D'Aprano  <steve+comp.lang.pyt...@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
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to