Steven D'Aprano added the comment:
I've found the same behaviour going back to Python 1.5.
I think what happens here is that (0+∞j)*1 evaluates the multiplication by
implicitly coercing the int to a complex:
(0+∞j)*(1+0j)
=> (0*1 + ∞j*1 + 0*0j + ∞j*0j)
=> (0-NAN + ∞j+0j)
=> (NAN + ∞j)
rather than using the "simple" way (1*0 + 1*∞j) => (0+∞j).
The problem here is that while there is no mathematical difference between
multiplying by 1 or (1+0j), once you involve NANs and INFs, it does. So even
though they give different answers, both methods are correct, for some value of
"correct".
I don't see that this is necessarily a bug to be fixed, it might count as a
change in behaviour needing to go through a deprecation period first. Perhaps
it should be discussed on python-ideas first?
My personal feeling is that Python should multiply a complex by a non-complex
in the "simple" way, rather than implicitly converting the int to a complex.
Anyone who wants the old behaviour can easily get it by explicitly converting 1
to a complex first.
So I guess this is a +1 to "fixing" this.
(Oh, the same applies to the / operator.)
----------
nosy: +steven.daprano
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24438>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
