Mark Dickinson wrote:
> (1) What about parentheses? The current complex repr and str have
> parentheses in them, for reasons that I still don't really understand.
> 
> I'd suggest leaving them out altogether;  except that I have
> the impression (perhaps wrongly) that an empty type code is
> supposed to correspond to str.  And given that I don't understand
> why the parens were in there in the first place, I'm probably
> not a good person to judge whether they should stay in a
> formatted complex number.

The rule is that if that x.__format__('') is equivalent to str(x). All 
of the built-in objects have a test for a zero-length format string and 
delegate to str(). But (3).__format__('-') does not call str(), despite 
the fact that it's the identical output. That's because the format 
string isn't zero-length. Instead, this is the case of the missing 
format "presentation type".

I couldn't find a case with any built-in objects where this really makes 
a difference (although I can't say I spent a lot of time at it). Complex 
would be the first one. But that doesn't really bother me.

format(1+1j, '')  -> '(1+1j)'
format(1+1j, '-') -> '1+1j'

Although I guess if we wanted to, we could say that the empty 
presentation type is equivalent to 'g', but gives you parens. This would 
fit in nicely with issue 5858, if it's accepted. Floats do something 
similar and special case the empty presentation type: '' is like 'g', 
but with at least one digit after the decimal point.

> (2) What about zeros?  The current repr and str leave out the real
> part (and the enclosing parens) if it's equal to zero.  Should
> format do the same?  I'd say not, except possibly again in the
> case where there's no type code.

I agree. Again, we could say that the empty presentation type is 
different in this regard.