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 lemburg
Recipients Retro, belopolsky, brian.curtin, georg.brandl, lemburg, mark.dickinson, michael.foord, pitrou, rhettinger
Date 2010-12-02.22:01:28
SpamBayes Score 4.0351056e-13
Marked as misclassified No
Message-id <4CF81737.8060508@egenix.com>
In-reply-to <1291325608.02.0.923899265835.issue10562@psf.upfronthosting.co.za>
Content
Mark Dickinson wrote:
> 
> Mark Dickinson <dickinsm@gmail.com> added the comment:
> 
> In all seriousness, the idea of accepting both 'i' and 'j' in complex() isn't horrible. I'm personally -0.small on it, mostly because it seems likely to lead to more objections about the complex str() and repr() *output* containing 'j's.  I still think python-ideas would be a more appropriate place for that discussion, though.

I think this falls under a "locale" problem of some sort...
engineers like 'j', mathematician prefer 'i'.

Personally, I think it's more important to be able to read
scientific data easily without too many problems, then to be
able to write the processed data in exactly the same way it
was read.

When formatting complex numbers, you have the issues
of whether to include spaces, parens, 'i' or 'j', so this
is better left to a application space function to deal with,
IMHO.

I would prefer to have str() and repr() always use the
parens and j notation - it makes recognizing complex numbers
easier, e.g. compare

(1+0j)
>>> 0+1j
1j
>>> 11
11

to

(1+0j)
>>> 0+1j
(0+1j)
>>> 11
11

(but I guess that another problem)
History
Date User Action Args
2010-12-02 22:01:29lemburgsetrecipients: + lemburg, georg.brandl, rhettinger, mark.dickinson, belopolsky, pitrou, Retro, michael.foord, brian.curtin
2010-12-02 22:01:28lemburglinkissue10562 messages
2010-12-02 22:01:28lemburgcreate