[Python-Dev] Python and the Unicode Character Database

[Steven D'Aprano]

Martin v. Löwis wrote:
> Am 30.11.2010 23:43, schrieb Terry Reedy:
>> On 11/30/2010 3:23 AM, Stephen J. Turnbull wrote:
>>
>>> I see no reason not to make a similar promise for numeric literals.  I
>>> see no good reason to allow compatibility full-width Japanese "ASCII"
>>> numerals or Arabic cursive numerals in "for i in range(...)" for
>>> example.
>> I do not think that anyone, at least not me, has argued for anything
>> other than 0-9 digits (or 0-f for hex) in literals in program code. The
>> only issue is whether non-programmer *users* should be able to use their
>> native digits in applications in response to input prompts.
> 
> 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! 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

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.

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.

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


-- 
Steven