Rough draft: Proposed format specifier for a thousands separator

[Rhodri James]

On Sat, 14 Mar 2009 08:20:21 -0000, Hendrik van Rooyen  
<mail at microcorp.co.za> wrote:

> "Tim Rowe" <dig....il.com> wrote:
>
> 8< -----------------------------------------------------------------
>
>> ......... If "Finance users and non-professional
>> programmers find the locale approach to be frustrating, arcane and
>> non-obvious" then by all means propose a way of making it simpler and
>> clearer, but not a bodge that will increase the amount of bad software
>> in the world.
>
> I do not follow the reasoning behind this.
>
> It seems to be based on an assumption that the locale approach
> is some sort of holy grail that solves these problems, and that
> anybody who does not like or use it is automatically guilty of
> writing crap code.
>
> No account seems to be taken of the fact that the locale approach
> is a global one that forces uniformity on everything done on a PC
> or by a user.

Like unicode, locales should make using your computer with your own
cultural settings a one-time configuration, and make using your
computer in another setting possible.  By and large they do this.

Like unicode, locales fail in as much as they make cross-cultural
usage difficult.  Unlike unicode, there is a lot of failure in the
standard locale library, which is almost entirely the fault of the
standard C locale library it uses.

Nobody's defending the implementation, as far as I've noticed
(which isn't saying much at the moment, but still...).  A bit of
poking around in the cheese shop suggests that Babel
(http://www.babel.edgewall.org/) would be better, and Babel with
a context manager would be better yet.


On the other hand, we have a small addition to format strings.
Unfortunately it's a small addition that doesn't feel terribly
natural in a mini-language that already runs the risk of looking
like line noise when you pull the stops out.  Not meaning the
term particularly unkindly, it is a bodge; it's quick and dirty,
syntactic saccharin rather than sugar for doing one particular
thing for one particular interest group, and which looks
deceptively like the right thing to do for everyone else.

That's a bad thing to do.  If we ever do get round to fixing
localisation (i.e. making overriding bits of locales easy), it
becomes a feature that's automatically present that we have
to discourage normal programmers from using despite it's
apparent usefulness.


Frankly, I'd much rather fix the locale system and extend
the format syntax to override the default locale.  Perhaps
something like

   financial = Locale(group_sep=",", grouping=[3])
   print("my number is {0:10n:financial}".format(1234567))

It's hard to think of a way of extending "%" format strings
to cope with this that won't look utterly horrid, though!

-- 
Rhodri James *-* Wildebeeste Herder to the Masses