Consider the following simple class that provides a "__complex__" method. class C(object): def __init__(self, x): self.x = x def __complex__(self): return self.x x=C(-0j) PYTHON 2.7.13 >>> x.x -0j >>> complex(x) 0j PYTHON 3.6 >>> x.x (-0-0j) >>> complex(x) (-0+0j)

Confirmed on my machine. The effect of the source is to do `complex(complex(x), 0.0)` in this case, which isn't correct.

Looking at the source, there's also an issue with complex subclasses here: >>> class C(complex): ... pass ... >>> complex(C(-0j)) (-0+0j) >>> complex(-0j) (-0-0j)

CPython 2.7 and 3.5 have issues with the sign of zeroes even without any custom class: >>> -(0j) # this is -(0+0j) (-0-0j) >>> (-0-0j) # but this equals to the difference between 0 and 0+0j 0j >>> (-0.0-0j) # this is the difference between -0.0 and 0+0j (-0+0j) >>> -0j -0j # <- on CPython 2.7 (-0-0j) # <- on CPython 3.5 It's unclear if the signs of the two potential zeroes in a complex number have a meaning, but the C standard considers these cases for all functions in the complex number's header.

Armin: that's a separate issue, and is expected behaviour. >>> -(0j) # this is -(0+0j) (-0-0j) Yes: 0j is complex(0.0, 0.0); negating negates both the real and imaginary parts. >>> (-0-0j) # but this equals to the difference between 0 and 0+0j 0j This is an operation between an integer (note that the initial negation is a no-op) and a complex. Here the integer gets promoted to complex(0.0, 0.0), and we do complex(0.0, 0.0) - complex(0.0, 0.0), which gives complex(0.0, 0.0). >>> (-0.0-0j) # this is the difference between -0.0 and 0+0j (-0+0j) This is complex(-0.0, 0.0) - complex(0.0, 0.0). The real and imaginary parts are operated on separately, and in keeping with IEEE 754, the real part is evaluated as -0.0 - 0.0, which is -0.0. >>> -0j -0j # <- on CPython 2.7 (-0-0j) # <- on CPython 3.5 The Python 3 behaviour here is correct. The Python 2 behaviour is the result of an unfortunate AST optimization designed to ensure that -<sys.maxint+1> is an int rather than a long. None of the above is a new issue.

> It's unclear if the signs of the two potential zeroes in a complex number have a meaning Yes, very much so. The signs are important in determining which side of a branch cut to use in the various cmath functions.

Maybe I should be more explicit: what seems strange to me is that some complex numbers have a repr that, when entered in the source, produces a different result. For example, if you want the result ``(-0-0j)`` you have to enter something different. However, I missed the fact that calling explicitly ``complex(a, b)`` with a and b being floats always gives exactly a+bj with the correct signs. So I retract my comments.

IMHO it would be less surprising if repr(complex) would return 'complex(..., ...)': it would be possible to copy/paste and get the result value. I was bitten multiple time by the zero sign with complex numbers...

Armin, Victor: please open other issues for these discussions; they're unrelated to the bug reported here. Also, see #27363, #17336, #22548, #25839.

Proposed patch fixes constructing complex from complex. But in future versions perhaps it is worth to disallow passing complex argument to two-arguments complex constructor.

4 lines before the new "ci.real = cr.imag;", we have "cr.imag = 0.0; /* Shut up compiler warning */". The comment is now wrong: we really need to set cr.imag to 0.0.

complex-constructor-from-complex2.patch looks good to me. What happens now? I presume we can no longer push to hg.python.org? So one of us needs to make a PR on GitHub and another review it?

I pushed changes to my fork but when try to create a pull request it contains unrelated changes. Seems I do something wrong.

Created https://github.com/python/cpython/pull/203, but I feel bad for having my name on the commits. :-(

 New changeset 112ec38c15b388fe025ccb85369a584d218b1160 by GitHub in branch 'master': bpo-29602: fix signed zero handling in complex constructor. (#203) https://github.com/python/cpython/commit/112ec38c15b388fe025ccb85369a584d218b1160 

 New changeset 4ddd89780fdb823f427c743ea7326a3c958a2f4b by Mark Dickinson in branch 'bpo-29549-backport': bpo-29602: fix signed zero handling in complex constructor https://github.com/python/cpython/commit/4ddd89780fdb823f427c743ea7326a3c958a2f4b 

 New changeset c0b336e0ada74b1242b9ef10c19eb87b0a21d106 by GitHub in branch '2.7': bpo-29602: fix signed zero handling in complex constructor (#204) https://github.com/python/cpython/commit/c0b336e0ada74b1242b9ef10c19eb87b0a21d106 

 New changeset 0936a00fe035e3e52c30bcbc59668dc0f519ced6 by GitHub in branch '3.5': bpo-29602: fix signed zero handling in complex constructor. (#203) (#205) https://github.com/python/cpython/commit/0936a00fe035e3e52c30bcbc59668dc0f519ced6 

 New changeset d9b3cdd137239a5913de2252c3ce269e35ac63d2 by GitHub in branch '3.6': bpo-29602: fix signed zero handling in complex constructor. (#203) (#206) https://github.com/python/cpython/commit/d9b3cdd137239a5913de2252c3ce269e35ac63d2 

I'm a bit puzzled about where the commit 4ddd89780fdb823f427c743ea7326a3c958a2f4b came from, but as far as I can tell the changes to 2.7, 3.5, 3.6 and master are all okay. All fixed. Thanks for the report!