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 veky
Recipients mark.dickinson, r.david.murray, veky
Date 2016-06-26.01:05:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1466903126.58.0.269374591681.issue27363@psf.upfronthosting.co.za>
In-reply-to
Content
Yes, but IMO that's a separate issue. And if complex analysis has taught me anything, it's that the sign of zero of .imag is much more important than the sign of zero of .real part (most elementary functions have branch cuts along real axis, where sign of .imag ensures continuity on both sides). Of course, having both would be even better, but having only this part is a good part of a good thing.

However, as I said, I know it's complicated. How about giving a "conventional" repr to complex? As far as I see, it's really not hard to implement - the only problem is backwards compatibility. But that was a problem when parentheses were added, too, right?

[ And there would be one more benefit: We could finally say goodbye to  weird "names" (infj, nanj) in the repr. By analogy with float, this could just be complex('nan', '-inf') or whatever. ]

For what it's worth, I'm not sure we should try too hard to preserve complex(repr(z)) being z given isinstance(z, complex). For example, Fraction and Decimal don't have this property (while it does kinda hold for str instead of repr, and it would continue to kinda hold for str here). Yes, I know Fraction and Decimal aren't builtins and complex is, but I really think it's only because of syntax support for j-based literals.
History
Date User Action Args
2016-06-26 01:05:26vekysetrecipients: + veky, mark.dickinson, r.david.murray
2016-06-26 01:05:26vekysetmessageid: <1466903126.58.0.269374591681.issue27363@psf.upfronthosting.co.za>
2016-06-26 01:05:26vekylinkissue27363 messages
2016-06-26 01:05:24vekycreate