On 28/11/2010 23:33, "Martin v. Löwis" wrote:
Even if this is somehow an accident or something that someone snuck in, I think it a good idea that *users* be able to input amounts with their native digits. That is different from requiring *programmers* to write literals with euro-ascii-digits
So one question is what kind of data float() is aimed at. I claim that it is about "programmer" data, not "user" data. If it supported "user" data, it probably would have to support "1,000" to denote 1e3 in the U.S., and denote 1e0 in Germany. Our users are generally confused on whether they should use th full stop or the comma as the decimal separator.
FWIW the C# equivalent is locale aware *unless* you pass in a specific culture. (System.Double.Parse):
If you're not aware that your code may be run on non-US computers this is a trap for the unwary. If you *are* aware then it is very useful.
An alternative overload allows you to specify the culture used to do the conversion:
As not even the locale-dependent issues are considered in float(), it is clear to me that entering local numbers cannot possibly be the objective of the function.
Instead, following a wide-spread Python convention, it is meant to be the reverse of repr().
Can you name a single person who actually wants to write '١٢٣٤.٥٦' as a number? I'm fairly skeptical that users of arabic-indic digits. Instead,
suggests that they would rather U+066B, i.e. '١٢٣٤٫٥٦', which isn't supported by Python.
Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...