TL;DR
Currency formatting has been an OS-level configuration for decades now, and the pre-internet days were a very different beast in terms of the frequency of international transactions and the need for someone in region A to express money using region B's currency.
I suspect the OS-centric currency settings are a relic of the past, kept in either because it simply hasn't been re-evaluated yet, or specifically to provide some backwards compatibility for older tools.
This not not about formatting
While some existing answers provide information and food for thought, I'm also noticing a lack of distinction being made between the choice of currency versus the choice of currency formatting.
While the formatting of currency makes sense to be a local machine decision, the currency symbol itself (not its location - which is also formatting) doesn't quite make sense to be decided by the machine instead of the data source which provided the monetary amount which needs to then be formatted.
It makes no sense for someone to tell me "It costs 100" and for me to then go "oh I prefer that those be 100 yen then!".
I agree on all of the formatting arguments making sense as local machine decisions, but not on the choice of the currency symbol itself, specifically.
What's the benefit of having the OS decide the symbol?
However, currency formatting (and all other numerical formatting) has been an OS-level configuration for decades now, and the pre-internet days were a very different beast in terms of the frequency of international transactions and the need for someone in region A to express money using region B's currency.
There's only one scenario where having this be a local machine decision makes sense:
- If you're developing software that you intend to sell in regions with a different currency
- If your customer's ecosystem itself only ever works in its own chosen currency, without ever changing. This could be a single machine, single customer, or a company who operates within one specific currency region.
This is the only case I can think of where this setting is not a problem and actually adds something of value.
In such a case, developers of the software don't need to explicitly account for any future customer's possible currency, in case their software sells well internationally. They wouldn't need to adjust and re-release their code just because their tool is now also being sold in another country.
Instead, they can just represent money numerically and label it as "whatever currency you (the client) uses", and then can blindly trust that the customer's machine presents this currency the way they like to see it.
When you are a customer whose entire ecoysytem (and therefore all input/output of that software) is in a single currency, then monetary values really can be represented as "just a number" to you, since you never need to distinguish between different currencies.
As a basic example, if you need to divide 100 moneys between 5 people, then each person gets 20 moneys. This is correct regardless of what currency you work with, as long as all the values I just used are expressed in the same currency.
However, if one of those people needs to be paid in USD and the others in EUR, then your elegant mathematical and currency-free calculation goes out the window.
With the advent of the internet and international transactions, the whole "single currency ecosystem" idea went straight out the door.
I suspect the OS-centric currency settings are a relic of the past, kept in either because it simply hasn't been re-evaluated yet, or specifically to provide some backwards compatibility for older tools.
print(f'${100:f}')
does not do any currency formatting. It simply prints the integer100
as a fixed point number with the default number of 6 decimals and adds the string prefix"$"
in front.