[Python-Dev] Python and the Unicode Character Database
Steven D'Aprano
steve at pearwood.info
Wed Dec 1 10:47:45 CET 2010
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
More information about the Python-Dev
mailing list