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”. > 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. -- \ “DRM doesn't inconvenience [lawbreakers] — indeed, over time it | `\ trains law-abiding users to become [lawbreakers] out of sheer | _o__) frustration.” —Charles Stross, 2010-05-09 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
