What I was trying to say was: I think of
ValueError as applying to a single ("bad") value
whereas ArithmeticError can arise from trying to combine
multiple ("good") values. It wouldn't be appropriate for
ArithmeticError to be a subclass of ValueError, because there is
no single erroneous value that you can point to.
Or more generally, any operation on multiple values, where each value is valid individually, but the result of the operation is not:
>>> p = Decimal('1E999999999')
>>> q = Decimal('10')
>>> try:
... p*q
... except ArithmeticError:
... print 'ArithmeticError'
...
ArithmeticError
On 25/05/2016 06:48, Guido van Rossum wrote:
Well, ZeroDivisionError doesn't derive from ValueError, does it? So it may not be a good idea, but it's certainly a tradition.
On Tuesday, May 24, 2016, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Guido van Rossum wrote:
It's very
common for modules to define their own root exception class.
And it's a nuisance when their exceptions only belong
to their own private hierarchy and don't participate in
any the standard classifications.
I don't think Decimal is directly to blame here, because
deriving its exceptions from ArithmeticError seems like
a reasonable thing to do. What *doesn't* seem reasonable
to me is that ArithmeticError doesn't derive from
ValueError. So far nobody has explained why that's
a good idea.
--
Greg
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
--
--Guido (mobile)
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/