Mark Dickinson <dicki...@gmail.com> added the comment: As Christian says, it's about not increasing code complexity without a good reason. For me, it's also about mental complexity: the set of valid inputs to the complex constructor should be small, and should be easy to understand and to describe.
The addition of the '*1j' part of the expression bothers me particularly, as does allowing complex('j') to be valid. I have a compromise proposal: 1. For nans and infs, get rid of the * on output: change repr so that e.g., repr(complex(0, nan)) is simply 'nanj', and repr(complex(inf,-inf)) is '(inf-infj)'. (Yes, I know it looks ugly, but bear with me.) 2. On input, allow strings of the form "complex-string" or "(complex- string)" where (in pseudo BNF): sign ::= '+' | '-' real-part ::= float-string imag-part ::= float-string 'j' complex-string ::= real-part [sign imag-part] | imag-part and float-string is any string currently accepted by float (excluding leading or trailing whitespace). Nothing else would be permitted. (Well, okay, we still have to allow whitespace around the complex string, both inside and outside the parentheses.) I think this would simplify the parsing, and remove need for special casing of nans and infs. It might even allow the code to become simpler, by sharing some of it with stuff in floatobject.c. The above would allow double signs: e.g. '2+-1j', with the first sign being the one explicitly described above and the second being part of the float-string. I don't think this is a terrible thing, if it simplifies parsing. It might even be helpful. For example: "%r+%rj" % (z.real, z.imag) would always be valid input. The current 'nan*j' is certainly more attractive than 'nanj', but it's just too suggestive of the actual expression float('nan')*1j, which it turns out doesn't produce the same thing. If you could come up with a patch that does something like this I'd take a look. By the way, "0 + inf*1j" giving nan + inf*j isn't really a bug; it's pretty much unavoidable: 1j is really complex(0, 1), and when multiplying by inf we get complex(inf*0, inf*1). With the usual IEEE 754 semantics inf*0 is nan. I think it's exactly to fix this sort of behaviour that C99 introduced its imaginary type (see Annex G of the standard). It doesn't seem to have caught on, though: I don't think gcc implements this, and I'd be very surprised if Visual Studio does. _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue2121> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com