Mark Dickinson wrote:
>> What should the format specifier mini-language for complex numbers look
>> like?
>> Should it look like the existing mini-language for floats, but have
>> the format specified twice, with some sort of delimiter?
> 
> This sounds clumsy to me.  I'd guess that in most uses you'd want the
> same format for both pieces.

I agree, and mostly I was just trying to spark some discussion and show 
how (absurdly) far we can take this.

>> Or just specified once, and use that for both parts?
> 
> That doesn't sound unreasonable.  But there might need to be some
> thinking about exactly what a '+' modifier means, or how you pad with
> zeros on the left when you've got two pieces to pad.

How about this:
- we have a single specifier with the same format as floats
- we force the sign on the imaginary part to be '+', no
   matter what was specified
- we add a 'j' after the imaginary part
- we ignore any width specified (and therefor any alignment
   and padding)

> It seems simplest just to tell people to format the real and imaginary
> parts by hand.  As it isn't totally obvious how to do this (e.g.,
> remembering the '+' for the imaginary part), perhaps there should be a
> recipe in the docs somewhere?

When we document the above approach, we note the way to get full control 
as mentioned in a prior message.

I guess we should put the docs in with string formatting (since that's 
where the other builtin types are documented), although really it 
belongs in complex.__format__ by itself. But I doubt anyone would find 
it there. Maybe we could to add a pointer from the string formatting to 
complex.__format__.