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

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

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