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.
--
http://mail.python.org/mailman/listinfo/python-list
