[Python-Dev] Python and the Unicode Character Database (original) (raw)

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