OK, let's not try to resolve that issue, we can just note it in the docs.
BTW I don't want repr() of a complex number to use the complex(..., ...)
notation -- it's too verbose.

On Tue, Jan 13, 2015 at 11:38 AM, Serhiy Storchaka <report@bugs.python.org>
wrote:

>
> Serhiy Storchaka added the comment:
>
> > Another possible "fix" is to introduce a new 'imaginary' type, such that
> the type of an imaginary literal is now 'imaginary' rather than 'complex',
> and arithmetic operations like addition can special-case the addition of a
> float to an 'imaginary' instance to produce a complex number with exactly
> the right bits. The C standardisation folks already tried this: C99
> introduces optional "imaginary" types and a new _Imaginary keyword, but
> last time I looked almost none of the popular compilers supported those
> types.  (I think Intel's icc might be an exception.)  While this works as a
> technical solution, IMO the cure is worse than the disease; I don't want to
> think about the user-confusion that would result from having separate
> "complex" and "imaginary" types.
>
> This type should exist only at compile time. Peephole optimizer should
> replace it with complex after folding constants.
>
> Or may be repr() (and str()) should keep zero real part if imaginary part
> is negative and output period if real part is zero. For now:
>
> >>> z = complex(0.0, 3.4); z; eval(repr(z))
> 3.4j
> 3.4j
> >>> z = complex(0.0, -3.4); z; eval(repr(z))
> -3.4j
> (-0-3.4j)
> >>> z = complex(-0.0, 3.4); z; eval(repr(z))
> (-0+3.4j)
> 3.4j
> >>> z = complex(-0.0, -3.4); z; eval(repr(z))
> (-0-3.4j)
> -3.4j
>
> But all this perhaps is offtopic here.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue23229>
> _______________________________________
>