Rough draft: Proposed format specifier for a thousands separator

[Raymond Hettinger]

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

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.

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.

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

The locale module has plenty of issues for a programmer to
think about:
http://docs.python.org/library/locale.html#background-details-hints-tips-and-caveats

Besides, lots of people use Python who are not professional
programmers.  We should not require them enter the complicated
world of locale just to do a basic formatting task.  When
I teach Python to pre-college students, there is no way I'm
adding locale to the list of things they need to learn to
become functional with the language.

Sorry for the long post, but I feel like you keep inventing
heavy solutions that don't fit well with what we already have.
This should be a simple problem -- when writing a number
format, how I specify that I want character X as a thousands
separator.  The answer to that question should be nothing
harder than, "add character X to the format string."

You're a very creative person, but I don't see Guido accepting
any idea that rejects what he has already chosen as the way
to format strings.  He is no fan of the locale module's API,
but it is tightly bound to existing programs and POSIX
standards.  That greatly limits the options for changing it.

I'm sure you can come-up with 500 ways of meeting this need
(almost none of which meld with Guido's choice to accept
PEP3101 for both 2.6 and 3.0).   I'm offering a simple
extension to the existing framework that makes the above
tasks easy.  C-sharp make essentially the same choice in its
design.  There's no reason for you to have to use it
if you hate it.

Cheers,


Raymond