Raymond Hettinger added the comment: IIRC, there have been previous discussions about little inconsistencies between when objects raise an OverflowError versus MemoryError and IndexError, and ValueError. I believe that Guido had opined that the choices were made somewhat arbitrarily (by different people at different times) but that it hadn't proved to be an actual problem in practice and that changing exception types after an API has already been released is more disruptive to users (potentially breaking existing, tested code) than living with the minor inconsistencies.
Guido, do you want these exceptions changed and do you agree with the Serhiy's new principles? My own thoughts are: * As a starting point, it seems reasonable to want consistent errors across ranges of input values. And being more predictable is a virtue as well. * Changing existing APIs is disruptive, making it more difficult to maintain cross-version code, breaking existing code or tests that use the current exceptions, and creating unnecessary work for Jython, IronPython, and PyPy who would have to follow our myriad of little changes. * Personally, I find OverflowError to be more self-explanatory of the cause of an exception than MemoryError which is more jarring and seemingly indicative of inadequate memory. * Likewise, Overflow error is more precise and helpful than ValueError which is very generic, covering a wide variety of problems. * A lot of third-party tools have evolved over time that mimic the behaviors of built-in types. If we change those behaviors now, the ecosystem will likely never fully sync-up. ---------- nosy: +gvanrossum _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29833> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
