Mark Dickinson <dicki...@gmail.com> added the comment:
See also #25839, #22548; there's lot of discussion of the core issue on those
tickets. As Serhiy says, the only reasonable "true" fix would be to have 1j be
a genuine imaginary literal, but that's a lot of work and potential disruption
(not just to core Python, but to 3rd party libraries that care about complex
numbers) for not a lot of gain.
A documentation improvement as suggested by Raymond sounds good.
I'm not keen on messing with the complex __repr__ again, but if we did, I'd
propose not only representing real and imaginary parts in a way that's
consistent with floats (so with both real and imaginary parts having either
decimal points or exponents), but also showing _both_ the real and imaginary
parts in all complex numbers. That is:
>>> 1j
0.0 + 1.0j
Or if we're willing to accept more backwards compatibility breakage, there's a
case for having the __repr__ (but not the __str__) of a complex number take the
form
>>> 1j
complex(0.0, 1.0)
since this the only way that allows easy round-tripping. Otherwise you still
have this problem:
>>> complex(-0.0, 1.0)
(-0+1j)
>>> -0 + 1j
1j
BTW, I still dislike the parentheses around the current complex repr.
Let's keep this issue open for potential documentation improvements. If we want
to change the repr of complex, let's open another issue for that.
----------
assignee: -> docs@python
components: +Documentation -Interpreter Core
nosy: +docs@python
type: behavior -> enhancement
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue40269>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
