This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author serhiy.storchaka
Recipients gvanrossum, mark.dickinson, pitrou, serhiy.storchaka, vstinner
Date 2015-01-13.19:38:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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))
>>> z = complex(0.0, -3.4); z; eval(repr(z))
>>> z = complex(-0.0, 3.4); z; eval(repr(z))
>>> z = complex(-0.0, -3.4); z; eval(repr(z))

But all this perhaps is offtopic here.
Date User Action Args
2015-01-13 19:38:01serhiy.storchakasetrecipients: + serhiy.storchaka, gvanrossum, mark.dickinson, pitrou, vstinner
2015-01-13 19:38:00serhiy.storchakasetmessageid: <>
2015-01-13 19:38:00serhiy.storchakalinkissue23229 messages
2015-01-13 19:38:00serhiy.storchakacreate