[Python-Dev] long(float('nan')) conversion (original) (raw)

Guido van Rossum guido at python.org
Fri Jan 4 18:19:30 CET 2008

On Jan 4, 2008 5:07 AM, Christian Heimes <lists at cheimes.de> wrote:

Bug http://bugs.python.org/issue1481296 describes a problem where long(float('nan')) causes a seg fault on Mac OS X. On other platforms it returns 0L, e.g.

Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32) [GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> float('nan') nan >>> long(float('nan')) 0L My patch to Python 2.6 adds an explicit check for NaNs to always return 0L. It did feel a bit strange but it's the default on some platforms. Today an user pointed out that he doesn't like the patch, too. How should the problem be solved? In my humble opinion long(float('nan')) should return 0L in Python 2.5.2 for b/w compatibility and raise a ValueError or OverflowError in Python 2.6+.

If long(nan) or int(nan) returns 0 on most platforms in 2.5, we should fix them to always return 0 in 2.5 and 2.6. In 3.0 they should raise ValueError.

It looks like long(inf) and int(inf) already raise OverflowError and that should stay.

We should make sure inf and nan are treated correctly by the new round(), floor() and ceil() in 3.0 -- it looks like right now round(nan) returns 0, but it should raise ValueError. (Also, Jeffrey, I thought math.floor() was to return an int? Or do I misremember?)

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list