Raymond Hettinger wrote:
[Jim Jewett]
Fair enough. But what does a thousands separator provide that the "n" type doesn't already provide? (Well, except that n isn't as well known -- but initially this won't be either.)
It's nice to be have a non-locale aware alternative so you can say explicitly what you want. This is especially helpful in Guido's example where you need to format for a different locale than the one that is currently on your machine (i.e. the global state doesn't match the target).
I've always thought that we should have a utility function which formats a number based on the same settings that are in the locale, but not actually use the locale. Something like: format_number(123456787654321.123, decimal_point=',', thousands_sep=' ', grouping=[4, 3, 2])
'12 34 56 78 765 4321,123'
That would get rid of threading issues, and you wouldn't have to worry about what locales were installed. I basically have this function in the various formatting routines, it just needs to be pulled out and exposed.
Do you really want a different type, such as "m" for money?
I don't but I'm sure someone does. I did write a money formatter sample recipe for the decimal docs so people would have something to model from.
This becomes easier with the hypothetical "format_number" routine. But this is all orthogonal to the str.format() discussion. Eric.