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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4