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 <rep...@bugs.python.org> <http://bugs.python.org/issue23229> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
