Message175671
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". |
|
Date |
User |
Action |
Args |
2012-11-16 09:05:21 | mark.dickinson | set | recipients:
+ mark.dickinson, casevh, kachayev |
2012-11-16 09:05:21 | mark.dickinson | set | messageid: <1353056721.91.0.00441958225745.issue16483@psf.upfronthosting.co.za> |
2012-11-16 09:05:21 | mark.dickinson | link | issue16483 messages |
2012-11-16 09:05:21 | mark.dickinson | create | |
|