Lennart Regebro writes:
On Tue, Nov 30, 2010 at 09:23, Stephen J. Turnbull firstname.lastname@example.org wrote:
Sure you can. In Python program text, all keywords will be ASCII
Yes, yes, sure, but not the contents of variables,
Irrelevant, you're not converting these to a string representation. If you're generating numerals for internal use, I don't see why you would want to do arithmetic on them; conversion is a YAGNI. This is only interesting to allow naive users to input in a comfortable way.
As yet there is no evidence that there are *any* such naive users, 1.3 billion of "possibles" are shut out, and at least two cultures which use non-ASCII numerals every day, representing 1.3 billion naive users (the coincidence of numbers is no coincidence), have reported that nobody in their right mind would would *input* the numbers that way, and at least for Japanese, the use cases are not really numeric anyway.
I see no reason not to make a similar promise for numeric literals.
Wait what, literas?
Sorry, my bad.
Why would this be a problem:
T1234 = float('~~~~.~~') T1234
But this OK?
T~~~~ = float('1234.56') T~~~~
(Sorry, the Arabic is going to get munged, my mailer is beta and somebody screwed up.)
Because the characters in the identifier are uninterpreted and have no syntactic content other than their identity. They're arbitrary. That's not true of numerics.
Because that works, but
doesn't (it prints ASCII). You can't round-trip, but users will want/expect that.
Because that works but this doesn't:
T1000 = float('一.◯◯◯')
If you're proposing to fix the numeric parsers, I still don't like it but I could go to -0 on it. However as Alexander points out and MAL admits, it's apparently not so easy to do that.