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 
way.  That is, instead of

>>> 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

for some additional discussion.

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.

> 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.

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.

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.