homepage

Hi, I think that TypeError should take precedence over InvalidOperation
in these two cases:
>>> Decimal('Infinity').fma(Decimal('0'), (3.91224318126786e+19+0j))
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/usr/local/lib/python3.2/decimal.py", line 1879, in fma
 'INF * 0 in fma')
 File "/usr/local/lib/python3.2/decimal.py", line 3926, in _raise_error
 raise error(explanation)
decimal.InvalidOperation: INF * 0 in fma
>>> 
>>> Decimal('1').fma(Decimal('snan'), 1.2222222222)
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/usr/local/lib/python3.2/decimal.py", line 1871, in fma
 return context._raise_error(InvalidOperation, 'sNaN', other)
 File "/usr/local/lib/python3.2/decimal.py", line 3926, in _raise_error
 raise error(explanation)
decimal.InvalidOperation: sNaN
>>>

Yes, I agree. Do you have a patch? I guess the only mildly tricky part here is making sure that the patch doesn't cause fma(2, 3, snan) (for example) to raise.

> cause fma(2, 3, snan) ...
Gah! That was nonsense. Please ignore.

Ok, I'll write a patch.

New changeset 825b4278a055 by Mark Dickinson in branch 'default':
Issue #12079: Decimal(0).fma(Decimal('inf'), 'not a number') should give a TypeError, not a Decimal.InvalidOperation
http://hg.python.org/cpython/rev/825b4278a055 

It turns out that this is as simple as moving the _convert_other call to the top of the Decimal.fma method. (For some reason I was confusing this with the subtleties involved in making sure that an InvalidOperation arising from the multiplication part of the fma takes precedence over an InvalidOperation coming from a signalling nan in the addend.)
Fixed.