This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients casevh, kachayev, mark.dickinson
Date 2012-11-16.09:05:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1353056721.91.0.00441958225745.issue16483@psf.upfronthosting.co.za>
In-reply-to
Content
I guess the feeling of wrongness for me mostly comes from the floating-point world, where the IEEE 754 'overflow' floating-point exception is only appropriate for cases where the result is *finite* but so large that it falls outside the representable range for a float.  Regarding conversions from floating-point formats to integer formats, IEEE 754 says: "When a NaN or infinite operand cannot be represented in the destination format and this cannot otherwise be indicated, the invalid operation exception shall be signaled." To the extent that there's a convention at all, we typically map 'invalid operation exceptions' to ValueError.  (See the comments at the top of Modules/mathmodule.c.)

There's also the minor practical inconvenience of having to remember to catch OverflowError *and* ValueError in try: .. except: constructs.

On the other side, there's a very real possibility of breaking code with this change.

I'll leave this open for a week or so, but unless there's a strong consensus that this should be changed, I propose to close as "won't fix".
History
Date User Action Args
2012-11-16 09:05:21mark.dickinsonsetrecipients: + mark.dickinson, casevh, kachayev
2012-11-16 09:05:21mark.dickinsonsetmessageid: <1353056721.91.0.00441958225745.issue16483@psf.upfronthosting.co.za>
2012-11-16 09:05:21mark.dickinsonlinkissue16483 messages
2012-11-16 09:05:21mark.dickinsoncreate