[issue27363] Complex with negative zero imaginary part

R. David Murray added the comment: Ah, I haven't used Fractions and Decimal much, so I hadn't noticed. Those postdate complex, I think, but do follow the model Mark is suggesting. Seems like it would be reasonble to make complex do the same...the concern of course is backward compatibilty.

[issue27363] Complex with negative zero imaginary part

Vedran Čačić added the comment: ...but hopefully not the last. People are playing (with BDFL's blessing) with the idea of types having just (qual)name as str. By "first stdlib case" you mean "first builtin case", right? fractions.Fraction and decimal.Decimal are in stdlib. :-) Yes, not all cl

[issue27363] Complex with negative zero imaginary part

R. David Murray added the comment: Right, that isn't the invariant. Eval is the normal invariant, but not all classes *can* meet it, in which case if they can provide a repr that *can* be turned back into the value losslessly somehow, that's better than not doing so at all. Still, changing t

[issue27363] Complex with negative zero imaginary part

Vedran Čačić added the comment: And of course, the most important argument that preserving type(x)(repr(x))==x is futile: try it with x=False. (Yes, bools are numbers too.:) On the other hand, of course, literal_eval treats 'False' completely fine. -- _

[issue27363] Complex with negative zero imaginary part

Vedran Čačić added the comment: 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

[issue27363] Complex with negative zero imaginary part

Mark Dickinson added the comment: > People usually say it's because we don't have separate imaginary type, but we > don't need it. I think we do. Consider the case of something like -0 + 1j (the `repr` of complex(-0.0, 1.0)). That currently evaluates to `complex(0.0, 1.0)`, because the `-0.0`

[issue27363] Complex with negative zero imaginary part

Vedran Čačić added the comment: 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"

[issue27363] Complex with negative zero imaginary part

Mark Dickinson added the comment: > I suspect that literal_eval, on the other hand, should reproduce what the > interpreter does I think that's going to be awkward to achieve without making the behaviour of literal_eval significantly less obvious and more DWIMmy. And I'm not convinced that `l

[issue27363] Complex with negative zero imaginary part

R. David Murray added the comment: That's a good point; however the goal of the "repr invariant" is to be able to losslessly reproduce the object when possible. The fact that you have to use the complex constructor to do that is unfortunate, but is a consequence of the underlying problem. I

[issue27363] Complex with negative zero imaginary part

Vedran Čačić added the comment: Funny, I thought the "repr invariant" was exactly the opposite thing, that _eval_ (or literal_eval) of repr should give back the starting object. And that's what I intended to preserve here. It's obviously broken now. Ok, alternate suggestion: can at least ast.l

[issue27363] Complex with negative zero imaginary part

R. David Murray added the comment: Breaking the repr invariant would be bad. Agree with rejection. -- nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker __

[issue27363] Complex with negative zero imaginary part

Mark Dickinson added the comment: Related: #17336, #22548, #25839 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscr

[issue27363] Complex with negative zero imaginary part

Mark Dickinson added the comment: This has been discussed in multiple issues before this one. Currently, `complex` from a string provides one of two ways to get a complex number with the correct signs for the real and imaginary parts; I'd hate to change that to give wrong results instead. The

[issue27363] Complex with negative zero imaginary part

New submission from Vedran Čačić: Look: >>> complex('1-0j') (1-0j) >>> 1-0j (1+0j) Yes, I understand what's going on, and it's probably wrong / too much to expect 1-0j to work properly, but I'd really like the complex from string constructor to be consistent with that. Even mo