[Python-Dev] Python and the Unicode Character Database

"Martin v. Löwis" martin at v.loewis.de
Wed Dec 1 23:32:25 CET 2010


>> And here, my observation stands: if they wanted to, they currently
>> couldn't - at least not for real numbers (and also not for integers
>> if they want to use grouping). So the presumed application of this
>> feature doesn't actually work, despite the presence of the feature it
>> was supposedly meant to enable.
> 
> By that argument, English speakers wanting to enter integers using
> Arabic numerals can't either!

That's correct, and the key point here for the argument. It's just not
*meant* to support localized number forms, but deliberately constrains
them to a formal grammar which users using it must be aware of in order
to use it.

> I'd like to use grouping for large
> literals, if only I could think of a half-decent syntax, and if only
> Python supported it. This fails on both counts:
> 
> x = 123_456_789_012_345

Here you are confusing issues, though: this fragment uses the syntax of
the Python programming language. Whether or not the syntax of the
float() constructor arguments matches that syntax is also a subject of
the debate.

I take it that you speak in favor of the float syntax also being used
for the float() constructor.

> The lack of grouping and the lack of a native decimal point doesn't mean
> that the feature "doesn't work" -- it merely means the feature requires
> some compromise before it can be used.

No, it means that the Python programming language syntax for floating
point numbers just doesn't take local notation into account *at all*.
This is not a flaw - it just means that this feature is non-existent.

Now, for the float() constructor, some people in this thread have
claimed that it *is* aimed at people who want to enter numbers in their
local spellings. I claim that this feature either doesn't work, or is
absent also.

> In the same way, if I wanted to enter a number using non-Arabic digits,
> it works provided I compromise by using the Anglo-American decimal point
> instead of the European comma or the native decimal point I might prefer.

Why would you want that, if, what you really wanted, could not be
done. There certainly *is* a way to convert strings into floats,
and there would be a way if that restricted itself to the digits 0..9.
So it can't be the mere desire to convert strings to float that make
you ask for non-ASCII digits.

> The lack of support for non-dot decimal points is arguably a bug that
> should be fixed, not a reason to remove functionality.

I keep repeating my two concerns:
a) if that was a feature, it is not specified at all in the
   documentation. In fact, the documentation was recently clarified
   to deny existence of that feature.
b) fixing it will be much more difficult than you apparently think.

Regards,
Martin



More information about the Python-Dev mailing list