2009/3/14 Hendrik van Rooyen <m...@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 -- http://mail.python.org/mailman/listinfo/python-list
