Rough draft: Proposed format specifier for a thousands separator

[Lie Ryan]

Raymond Hettinger wrote:
> [Lie Ryan]
>>  >     In the finance world, output with commas is the norm.
>>
>> I can't cite any source, but I am skeptical with that.
> 
> No doubt that you're skeptical of anything you didn't
> already know ;-)  I'm a CPA, was a 15 year division controller
> for a Fortune 500 company, and an auditor for an international
> accounting firm.  Believe me when I say it is the norm in finance.
> Besides, it seems like you're arguing that thousands separators
> aren't needed anywhere at all and have doubts about their
> utility.  Pick-up your pocket calculator and take a look.
> Look at your paycheck or your bank statement.  Check-out a
> publishing style guide.  They are somewhat basic.  There's
> a reason the MS Excel and Lotus offered them from day one.

I have no reason to doubt that output with separators is nice, but I am 
skeptical that all financial institution in the world (not just US) uses 
commas for their separators.

> Python's format() style was taken directly from C-Sharp.
> which offers both an "n" format that is locale sensitive
> and a non-locale-sensitive variant that specifies a comma.
> I'm suggesting that we also do both.

I'm fine with that. But no commas, instead user-defineable separators.

> Random, make-up statistic:  99% of Python scripts are
> not internationalized, have no need to be internationalized,
> and have output intended to be used in the script writer's
> immediate environment.

Random, make up statistic: 95% of which is scripts written for 
personal/internal use.


 > If you
 > do find such a locale and it happens to be spelled the same
 > way on every platform, is it self-evident in your program
 > that it will in fact print with spaces or has that become
 > an implicit, behind the scenes operation.  If later you need
 > to print another number with a different separator, do you
 > have a way make that happen without breaking the first piece
 > of code you wrote?

Yeah, every data in transmission should be in locale independent format, 
it should only be turned to locale aware format just before viewing to 
the user. That way nothing will break.

Since you're an accountant, I am sure you know about Quicken Files, 
which stores data in locale format, which IMHO is a very BAD design.




> Another issue I have with locale is that you have to find
> one that matches every specific need.  Quick, which one gives
> you non-breaking spaces for a thousands separator?  

That wasn't the issue. Most programs would either "use the environment's 
locale and give user configuration to override the locale" or "I don't 
care, the output is for personal/internal consumption" or "The data only 
makes sense with certain formatting". I don't see a use case where the 
programmer would really want to hardcode a locale AND want the output to 
be exactly like what he sees in the user machine.

The first case ("use the environment's locale and give user 
configuration to override the locale") is for internationalized 
applications, and is served by locale. The locale module is currently 
difficult to work with, so I believe we should provide a more accessible 
way.

The second case ("I don't care, the output is for personal/internal 
consumption"), is well served by python's default view.

The third case ("The data only makes sense with certain formatting") is 
the one that will benefit the most from non-locale aware formatting. But 
they would require a very powerful formatter. Such use case is 
formatting IP address, telephone number, ID card number, etc.

My proposition is: make the format specifier a simpler API to locale 
aware or make it capable to serve the third case. I would rather 
prioritize on the former case.