From: Richard Damon <rich...@damon-family.org> On 6/23/18 11:27 AM, Steven D'Aprano wrote: > On Sat, 23 Jun 2018 09:42:29 -0400, Richard Damon wrote: > >> On 6/23/18 9:05 AM, Marko Rauhamaa wrote: >>> Ok. Here's a value for you: >>> >>> 100ΓΘ¼ >>> >>> I see '1', '0', '0', 'ΓΘ¼'. What do you see in your locale (LC_MONETARY)? >> If I processed that on my system I would either get $100, or an error of >> wrong currency symbol depending on the error checking. > Then your system is so unbelievably broken that it should be nuked from > orbit, just to be sure. > > The data you were given was 100 Euros. If your system is incapable of > reading that as 100 Euros, and errors out, then at least to know that it > is brain-damaged and useless. > > But if instead it silently changes the data to $100 (US dollars? > Australian dollars? Zimbabwe dollars? the gods only know what a system > that broken might do...) then it is not only broken but *dangerously* > broken. > Locale based currency transformations are defined as a number to/from a text string.
The number CAN'T say 100 Euros (can you give me what bit pattern you would use for such a number). The currency is encoded in the locale used for the conversion, so if it is using en-US, the currency value would ALWAYS be US$ (which the general locale format is just $). As such 100ΓΘ¼ is an invalid input to a system getting a Locale based input for a currency if the locale is not one from a country that uses the euro. What the input sees is '1', '0', '0',Γ some funny character (or maybe 2 of them). A poorly designed input, or one being intentionally generous on input acceptance would return 100, which would be implied US Dollars. A better error checking routine would give an error. It is IMPOSSIBLE for it to return a number that would be 100 euros. I suppose a very smart system might see that it was in a different currency and try to convert it, but unless time reference point to use for the currency, you are likely to get a wrong answer, but in any case, the answer will NOT be 100 euros, but some equivalent value in Dollars. Now, if you want to define a perhaps more general currency input routine that tries to detect a pan-locale currency input, and returned both a value and a currency type, that could be more useful in some contexts. But you then run into the interesting (and difficult) problem that if you see the input of 123.456ΓΘ¼ what is that value, is it a value around a hundred euros specified to 3 decimal places, or is it a number just over 100 thousand euros. > > [...] >> Locale predates UCS-2, it was the early attempt to provide >> internationalization to C code so even programmers who didn't think >> about it could add the line setlocale(LC_ALL, "") and make their code >> work at least mostly right in more places. A single global was quick and >> simple, and since threads didn't exist, not an issue. > Threads were first used in 1967, five years before C even existed. > > https://en.wikipedia.org/wiki/Thread_%28computing%29#History > Threads did NOT exist (at least to the Standard) in C when locales were added, and the C language did nothing to support threading at that time. Looking back, it was perhaps a regrettable decision to implement locales globally the way there were, but it is what it is. -- Richard Damon --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
