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.

classification
Title: Type: Make complex repr and str more like float repr and str enhancement needs patch Interpreter Core Python 3.1
process
Status: Resolution: closed rejected mark.dickinson eric.smith, mark.dickinson, rhettinger high

Created on 2009-04-27 20:45 by mark.dickinson, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)
msg86692 - (view) Author: Mark Dickinson (mark.dickinson) * Date: 2009-04-27 20:45
```In all current versions of Python, the str or repr of a float always
includes *either* an exponent, or a decimal point and at least one digit
after the decimal point.

I propose making the str or repr of a complex number behave in the same

>>> 2+4j
(2+4j)

we'd have:

>>> 2+4j
(2.0+4.0j)

The aims are to make complex representation more consistent with float
representation, retain the visual reminder that the pieces of a complex
number are floats (to me, 2+4j looks like a Gaussian integer rather than
a complex number), simplify the implementation a little, and remove the
ugliness where floats switch from normal to exponential notation at
1e11, but complex numbers switch at 1e12.

See

http://mail.python.org/pipermail/python-dev/2009-April/089030.html

msg86694 - (view) Author: Raymond Hettinger (rhettinger) * Date: 2009-04-27 20:57
```This should probably be discussed somewhat that all the numpy/numeric
folks can see it (since they likely comprise the largest group of users
of complex numbers).

Also note that any changes to representations tend to break peoples
doctests.  Those are particularly susceptible to this change because
of people using whole numbers for hand entered test inputs.

FWIW, Octave starts with 2+4j style formatting but if either component
has a decimal, then both switch 2.1000 + 4.000j.

My own tastes prefer the current form, but I would probably adapt quickly.```
msg86697 - (view) Author: Mark Dickinson (mark.dickinson) * Date: 2009-04-27 21:08
```> This should probably be discussed somewhat that all the numpy/numeric
> folks can see it.

Good point; I'll post something to the numpy/scipy mailing list and see if
I can get some reactions.

> Also note that any changes to representations tend to break peoples
> doctests.

This is the biggest minus right now for me, and it's the reason that I'm
only proposing this for 3.1, not for 2.7.  (I guess 3.0 would have been
better.)  My main motivation for this change came from seeing the extra
gymnastics required to special-case complex numbers in Eric's new
formatting code; the rest is just personal taste, I guess.```
msg86723 - (view) Author: Mark Dickinson (mark.dickinson) * Date: 2009-04-28 10:36
```I'm still flip-flopping on this one.  On the minus side, this change
risks breaking doctests without any enormous gain to show for it.

On the plus side, Eric Smith is currently working on implementing
sensible formatting for complex numbers (issue 1588), and again the
current form of complex formatting is going to cause (minor,
surmountable, but still ugly) difficulties for that implementation
when the empty presentation type is being used (e.g., format(3j, '')
or format(3j, '<20')).

I'll come up with a patch and see how much breaks in core Python.```
msg86962 - (view) Author: Mark Dickinson (mark.dickinson) * Date: 2009-05-02 18:16
```I'm not going to pursue this further;  try as I might, I really can't
make this anything more than just a personal preference.  It doesn't
solve any genuine problem.

Closing.```
History
Date User Action Args