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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4