[Python-ideas] Should decimal.InvalidOperation subclass ValueError?

Steven D'Aprano steve at pearwood.info
Sun May 22 09:31:52 EDT 2016


On Sun, May 22, 2016 at 10:15:16AM +0000, Stefan Krah wrote:
> Steven D'Aprano <steve at ...> writes:
> > So I propose that InvalidOperation be changed to inherit from
> > ValueError, to match the expected behaviour from other numeric types.
> 
> One problem is that often a *combination* of values triggers InvalidOperation.
> ValueError does not really fit here.

I don't see why it matters whether it is one value or a combination of 
values, it's still a value error.


>  In this scenario other modules use
> TypeError, but I'm not a fan of that use either:
> 
> >>> Decimal("inf") * Decimal(0)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> decimal.InvalidOperation: [<class 'decimal.InvalidOperation'>]

I'm not sure what you mean by this example, and what it has to do with 
TypeError. The error shown is related to the *value* of the arguments, 
namely Decimal inf and Decimal zero, not their types. Both arguments are 
Decimal.


> >>> Decimal("inf") * Decimal("inf")
> Decimal('Infinity')

Again, I don't see the relevance of this example. Multiplying Decimal 
infinity by another Decimal infinity is well-defined, and not an error.


> Additionally, InvalidOperation is part of Decimal's custom exception handling
> via the context, so it would be a bit odd if ValueError were part of that.

Perhaps I am mistaken, but none of Decimal's custom exception handling 
would need to change. That's the beauty of multiple inheritence. If we 
add ValueError as a base class, InvalidOperation is a subclass of both 
DecimalException and ValueError. The custom exception handling will 
continue to work the same way it does now, and people who expect 
Decimal("spam") to raise ValueError will also be satisfied.



-- 
Steve


More information about the Python-ideas mailing list