Rough draft: Proposed format specifier for a thousands separator

[Tim Rowe]

2009/3/14 Hendrik van Rooyen <mail at microcorp.co.za>:

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

Not so. Under .NET, for instance, the global settings will give you a
default CultureInfo class, but you can create your own CultureInfo
classes for other cultures in your program and use them in place of
the default.

> So when you want to make a report in a format that would suit
> what your foreign visitors are used to, do you have to change
> your server's locale, and change it back again afterwards, or what ?

No, you create a local locale and use that.

There are essentially three possible levels I can see for this:

- programs that will only ever be used in one locale, known in
advance. They can have the locale hard-wired into the program. No
special support is needed for this. It's pretty easy to write a
function to format a number to a hard-wired locale. I've done it in
Pascal and FORTH and it was easy-peasy, so I can't imagine it's going
to be a big deal in Python. If it's such a big deal for accountants to
write this code, if they ask in this forum how to do it somebody will
almost certainly supply a function that takes a float and returns a
formatted string within a few minutes. It might even be you or me.

- Programs that may be used in any unchanging locale. The existing
locale support is built for this case.

- Programs that nead to operate across locales. This can either be
managed by switching global locales (which you rightly deprecate) or
by managing alternate locales within the program.

> The locale approach has all the disadvantages of global variables.

No, it has all the advantages of global constants used as overridable
defaults for local variables.

> To make software usable by, or expandable to, different languages
> and cultures is a tricky design problem - you have to, at the
> minimum, do things like storing all your text, both for prompts and
> errors, in some kind of database and refer to it by its key, everywhere.
> You cannot simply assume, that because a number represents
> a monetary value, that it is Yen, or Australian Dollar, or whatever -
> you may have to convert it first, from its currency, to the currency
> that you want to display it as, and only then can you worry about
> the format that you want to display it in.

Nothing in the proposal being considered addresses any of that.

-- 
Tim Rowe