[issue1481296] long(float('nan'))!=0L
Mark Dickinson [EMAIL PROTECTED] added the comment: New patch committed, r65518. Conversion of a nan to an integer now raises ValueError consistently across platforms. -- status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1481296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1481296] long(float('nan'))!=0L
Antoine Pitrou [EMAIL PROTECTED] added the comment: It also just feels right, to me; an attempt to convert a nan to an integer should not pass silently. I have the same gut feeling. -- nosy: +pitrou ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1481296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1481296] long(float('nan'))!=0L
Mark Dickinson [EMAIL PROTECTED] added the comment:
I still think this is the wrong solution, and should be fixed before 2.6;
long(float('nan')) should raise ValueError. As Alexander points out,
this fits much better with the IEEE 754 standard, and also with the C99
standard. It also just feels right, to me; an attempt to convert a nan
to an integer should not pass silently.
Here's a patch, based on Ronald's original patch.
Christian, what was the motivation for returning 0 here?
(One could also argue on the basis of IEEE 754 and C99 that
long(float('inf')) should raise ValueError instead of OverflowError;
personally, I'm content that long(float('inf')) raises an exception---I'm
not too bothered which one.)
I agree that there doesn't seem much value in backporting the fix.
--
keywords: +patch
Added file: http://bugs.python.org/file10957/issue1481296.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1481296
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1481296] long(float('nan'))!=0L
Changes by Georg Brandl [EMAIL PROTECTED]: -- priority: normal - critical status: closed - open ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1481296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1481296] long(float('nan'))!=0L
Mark Dickinson [EMAIL PROTECTED] added the comment: Assigning to me; I'd like to check in the new fix for 2.6/3.0, but I'll give it a couple of weeks for any objections to surface first. -- assignee: - marketdickinson versions: +Python 2.6, Python 3.0 -Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1481296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1481296] long(float('nan'))!=0L
Georg Brandl [EMAIL PROTECTED] added the comment: It seems backporting this is not useful. -- nosy: +georg.brandl status: pending - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1481296 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1481296] long(float('nan'))!=0L
Alexander Belopolsky added the comment: FYI: IEEE Standard 754 requires an invalid operation exception when inf/nan conversion to integer is attempted. -- nosy: +belopolsky _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1481296 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1481296] long(float('nan'))!=0L
Mark Dickinson added the comment: A late comment: I agree with Ronald here; mightn't it make more sense to raise an exception (ValueError?) for long(float(nan))? For comparison, long(float(inf)) currently raises OverflowError, at least on OS X. -- nosy: +marketdickinson _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1481296 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1481296] long(float('nan'))!=0L
Christian Heimes added the comment: Fixed in r59689 trunk Backport it to 2.5? -- nosy: +tiran resolution: - fixed status: open - pending versions: +Python 2.5 -Python 2.3 _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1481296 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1481296] long(float('nan'))!=0L
Ronald Oussoren added the comment: The change in the trunk seems like a good backport candidate, it fixes an issue with float conversion on OSX compared to other platforms. That said, I don't like the patch. This makes the current behaviour of converting float NaN's to 0 the defined behaviour, which feels wrong (he says without having the slightest idea of what the relevant standards might say about this). Shouldn't this raise an exception instead of silently converting? _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1481296 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
