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-25.12:22:49
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1466857370.88.0.9298473656.issue27363@psf.upfronthosting.co.za>
In-reply-to
Content
Mark, I think it would be a great idea. It would be consistent with both "str is straightforward, repr is reproducible", and with the idea that (evalable) repr is almost always of the form `typename(arguments)`. It would also get rid of that "supefluous-looking" parentheses around the repr, and put them in the right place: a call. :-)

[ On the other hand, I started to think deeply about the reason why we cannot make 1-0j do the right thing, and I'm not so sure anymore. People usually say it's because we don't have separate imaginary type, but we don't need it: all we need is a separate _real_ type, and we have it: float.

When Python subtracts 0j from a float 1.0, there is no absolute imperative that it has to do it in the same way as subtracting 0j from a complex(1.0, 0.0). We _can_ make it so the result of the former is complex(1.0, -0.0), and result of the latter is complex(1.0, 0.0).

Of course, now even the imaginary complex numbers couldn't be outputed simply, and -0 real part should become -0.0, but it might be worth it. I understand it's enormously complicated though, and I'd be satisfied with a "normal" repr. Or a literal_eval that really understand complex numbers' repr. ]
History
Date User Action Args
2016-06-25 12:22:50vekysetrecipients: + veky, mark.dickinson, r.david.murray
2016-06-25 12:22:50vekysetmessageid: <1466857370.88.0.9298473656.issue27363@psf.upfronthosting.co.za>
2016-06-25 12:22:50vekylinkissue27363 messages
2016-06-25 12:22:49vekycreate