Author eric.smith
Recipients ajaksu2, eric.smith, gvanrossum, mark, mark.dickinson
Date 2009-04-27.11:32:07
SpamBayes Score 2.77517e-12
Marked as misclassified No
Message-id <>
In-reply-to <>
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 
Date User Action Args
2009-04-27 11:32:10eric.smithsetrecipients: + eric.smith, gvanrossum, mark.dickinson, ajaksu2, mark
2009-04-27 11:32:08eric.smithlinkissue1588 messages
2009-04-27 11:32:07eric.smithcreate