On 2016-08-26 22:25, Ken Kundert wrote:
Okay, so I talked to Guido about this, and all he was trying to convey is that
there is an extremely high bar that must be reached before he will consider
changing the base language, which of course is both prudent and expected.
I'd like to continue the discussion because I believe there is some chance
that we could reach that bar even though Guido is clearly skeptical.
At this point I'd like to suggest that there be two more constraints we
consider:
1. whatever form we choose to be used when outputting numbers should the same
form we use when inputting numbers (so %r should produce valid python input,
as does all the other format codes),
2. and whatever form we choose to be used when outputting numbers should look
natural to end users.
So ideas like using 2.4*G, 2.4*GHz, or 0s2.4G wouldn't really work because we
would not want to output numbers to end users in this form. Even 2.4_GHz, while
better, would still look somewhat unnatural to end users.
"2.4" would not look natural to a lot of people; they would expect "2,4".
Either you force the end user to accept what Python uses for a decimal
point and digit grouping, or you convert on input and output.
And if you're doing that for the decimal point and digit grouping, you
might as well also do that for scale factors and units.
One more thing to consider is that we already have a precedent here. Python
already accepts a suffix on real numbers: j signifies an imaginary number. In
this case the above constraints are satisfied. For example, 2j is a natural form
to show any end user that understands imaginary numbers, and 2j is acceptable
input to the language. To be consistent with that, it seems like 2G or 2GHz
should be preferred over 2_G or 2_GHz.
Of course, this brings up another issue, how to we handle imaginary numbers with
scale factors. The possibilities include:
1. you don't get them, you can either specify j or a scale factor, but not both
2. you do get them, but if we allow units, then j should be first
3. you do get them, but we don't allow units and j could be first or second
I like choice 2 myself. Also, to be consistent with j, and because I think it is
simpler overall, I think 2G should be a real number, not an integer. Similarly,
I think 2Gi, if we accept it, should also be a real number, simply for
consistency.
One last thing, we can accept 273K as input for 273,000, but when we output it
we must use k to avoid confusion with Kelvin (and because that is the standard).
Also, we can use μ for for inputting or outputting 1e-6, but we must always
accept u as valid input.
Interestingly, it's not possible to use J as a unit (Joule):
>>> 1J
1j
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
