Mark Dickinson added the comment: 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". ---------- assignee: -> mark.dickinson _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16483> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com