In Python, the letter 'j' denotes the imaginary unit. It would be great if we would follow mathematics in this regard and let the imaginary unit be denoted with an 'i'.

Nobody these days uses j to represent the imaginary part of complex numbers. Regardless of what Guido wrote earlier, this issue should be fixed.

Your statement is not correct. A lot of people use "j" in fields of electrical engineering and signal processing to express the imaginary part. The letter "i" is commonly used for electric current in these fields.

Even if we wanted to switch to "i" we'd have to continue to also support "j": there's a ton of existing code that uses it. Since "j" is used by some fields (including my own) for the imaginary part of complex numbers, and since I don't think we want to have two ways to do the same thing, I think this proposal should be objected.

But if you really want to pursue it, I suggest starting a discussion on the python-ideas mailing list.

Personally, it's more natural use 'j' for complex number, but it's true that in many math book (or that I used) letter 'i' is used.

Now, it's feasible change i for j on cpython? Asking from my ignorance on this case.

> Now, it's feasible change i for j on cpython? Asking from my ignorance on this case.

j for i, sorry

As I said in msg385648, I don't think it's feasible.

Maybe I'll write a PEP just to get it rejected so we can point to it when this discussion comes up, which it does a few times a year.

https://mathworld.wolfram.com/j.html

D and SmartBASIC use a literal suffix "i" for imaginary numbers. I can't 
find any other languages which support literal syntax for complex 
numbers, but I haven't looked very far.

https://www.researchgate.net/profile/Ken_Hawick/publication/267386724_Notes_on_Complex_Numbers_for_Computer_Scientists/links/54c7474f0cf238bb7d0a5c67/Notes-on-Complex-Numbers-for-Computer-Scientists.pdf

https://en.wikipedia.org/wiki/Complex_data_type

I don't think it really matters what other languages do. We're not designing this from scratch. We need to reflect that state we're in, which is many, many lines of working code using 'j'. I see the two options as: support 'i' and 'j', or break existing code and switch to 'i'. I don't think either option makes sense.

I think it always helps to look at what other languages do. It doesn't 
mean that we must follow them, but it may help us decide that the choice 
made in Python 1 was a mistake and it is worth going through the pain of 
deprecation, or that it is still justified and we should stick to the 
current design. If everyone else is making a different decision, it pays 
to at least consider why. If they're making the same decision we did, 
that helps justify what we did.

For what it's worth, although my personal preference would be for i, I 
think that going through a disruptive deprecation period is not 
justified. j is good enough. I haven't got an opinion on supporting both 
i and j.

Eric, if you do follow through with writing a PEP, remember that you 
have to make the best case that you can for the change. And you might be 
surprised: when Guido volunteered me to write the dict addition PEP, I 
initially intended it to be rejected. I never expected that it would be 
accepted with a change of operator.

Good point on surveying other languages for a PEP. You're further along in your thinking than I am!

See also #10562.

Conceivably, we could add support for `i` on parsing (along with adding `cmath.infi` and `cmath.nanj`). We can probably also find a way to extend the format specification to allow use of `i` in place of `j` on output. The harder problem would be changing the repr and str of complex without breaking existing code. I doubt that the OP would be satisfied with the following:

>>> 3 + 4i
(3+4j)

> cmath.nanj

That should be cmath.nani, of course. Sorry.

Only yesterday I thought about proposing this idea. I used to think using "i" or "j" was a type of local feature, like using a comma or a period as a decimal separator, or different writing for less-or-equal, but it looks like even in the English-speaking world mathematics use "i", and "j" is only used by electric engineers.

Possible argument against the "i" suffix is that its capital form "I" can be confused with the "l" suffix for longs (but it is no longer applicable in Python 3) and digit "1". Although there is more similarity between "l" and "1" them between them both and "I", and there are other pairs of potentially confusing characters: "O" (for octals) and "0", "B" (for binaries) and "8".

Serhiy: what *specific* proposal were you considering? If your proposal includes changing the complex str/repr to use "i" instead of "j", how do you propose to address the backwards compatibility problem?

Just making the parser (and the complex constructor) recognizing "i" as well as "j" as complex number suffix. Others already proposed more complex changes like adding options for formatting complex numbers, but I did not though about it. It is just a coincidence that I though about this idea in the same day as the OP opened the issue.

[Serhiy]

> Just making the parser [...] recognizing "i" as well as "j" as complex number suffix.

Okay, thanks. I doubt that that will be enough to silence the repeated requests: people are still going to complain that the value that was entered as `1i` is being displayed as `1j`. I don't see a sane path towards changing that.

Unfortunately, this ship sailed a long time ago.  Changing it now would create more problems that it solves.

> I doubt that that will be enough to silence the repeated requests:
> people are still going to complain that the value that was entered
> as `1i` is being displayed as `1j`. I don't see a sane path 
> towards changing that.

Exactly this.

@Eric: Are you okay with closing this issue, or do you think we should leave it open as a reminder to write that PEP?

Thanks, Mark. I'll just close it now. I've made a reminder about the PEP, but not sure when/if I'll get to it.