From: Richard Damon <rich...@damon-family.org> On 6/23/18 5:31 PM, Ben Finney wrote: > Richard Damon <rich...@damon-family.org> writes: > >> On 6/23/18 11:27 AM, Steven D'Aprano wrote: >>>> On 6/23/18 9:05 AM, Marko Rauhamaa wrote: >>>>> Richard Damon wrote: >>>>>> Data presented to the user should normally use his locale >>>>>> (unless he has specified something different). >>>>> Ok. Here's a value for you: >>>>> >>>>> 100ΓΘ¼ >>>>> >>> [Γ |] >>> 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. >>> >> [Γ |] >> >> The number CAN'T say 100 Euros (can you give me what bit pattern you >> would use for such a number). > That is (I believe) the point being made: The data is *not* a number. It > is a value that must encapsulate more than only the number 100, but also > and simultaneously the curency Γ úEuroΓ ╪. If you have more than just a number representing a value in the locale currency, you can't ask the locale how to present/accept it. > >> 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. > The value is 100 Euro, a quantity of a particular currency and not > something trivially converted to US$ (for many reasons, including the > obvious one that we don't know the exact exchange rate to use, and it > will be different at a different time). > > You appear to be arguing that this value must either be arbitrarily > converted to the user's local currency, something we agree is impossible > to do given the data, or the value is simply invalid. > > So the rule you assert Γ ⌠ Γ úData presented to the user should normally use > his localeΓ ╪ Γ ⌠ fails to usefuly handle the very normal case of data that > represents a quantity of some foreign currency. Any system following > your asserted rule will give either the wrong answer, or an error. We > had better hope the rule you assert is not in effect. > If the user wants to talk in Euro using software that uses locales, then he should specify a locale that uses Euros.
If you have a field to enter a foreign currency, then you can NOT make that a LC_CURRENCY field, or you need to make that field use a different locale than the local locale. This isn't the fault of locales, but in a misuse of the system. This original question came when it was asked what do I see with 100ΓΘ¼ in MY locale LC_CURRENCY, well MY locale doesn't have a LC_CURRENCY that is euros, so it can't express that. It is a bit like asking how to draw a circle with 4 straight lines or get to the moon in a boat. It is a question with an improper premise. -- Richard Damon --- BBBS/Li6 v4.10 Toy-3 * Origin: Prism bbs (1:261/38) -- https://mail.python.org/mailman/listinfo/python-list
