On 8/26/2016 8:47 AM, Steven D'Aprano wrote:
This leads to my first proposal: require an explicit numeric prefix on numbers before scale factors are allowed, similar to how we treat non-decimal bases.
8M # remains a syntax error
-1 for the syntax, +1 for keeping it an error
0s8M # unambiguously an int with a scale factor of M = 10**6
-.5, better 0a for a in b,o,x is used for numeral base, which is related to scaling of each numeral individually. 0s would be good for ancient sexigesimal (base 60) notation, which we still use for time and circle degrees.
Or if that's too heavy (two whole characters, plus the suffix!) perhaps we could have a rule that the suffix must follow the final underscore of the number:
8_M # int 8*10*6 123_456_789_M # int 123456789*10**6
-.1, better
I do not remember seeing this use of SI scale factors divorced from units. I can see how it works well for the relatively small community of EEs, but I expect it would only make Python more confusing for many others, especially school kids.
Proposal number two: don't make any changes to the syntax, but treat these as *literally* numeric scale factors. Add a simple module to the std lib defining the various factors:
+1 for PyPI, currently +-0 for stdlib '*' is easier to type than '_'.
k = kilo = 10**3 M = mega = 10**6 G = giga = 10**9
etc. and then allow the user to literally treat them as scale factors by multiplying:
from scaling import * int_value = 8*M float_value = 8.0*M fraction_value = Fraction(1, 8)*M decimal_value = Decimal("1.2345")*M
A main use for me would be large ints: us_debt = 19*G. But I would also want to be able to write 19.3*G and get an int, and that would not work. The new _ syntax will alleviate the problem in a different way. 19_300_000_000 will work. Rounded 0s for counts do not always come in groups of 3.
and so forth. The biggest advantage of this is that there is no syntactic changes needed, it is completely backwards compatible, it works with any numeric type and even non-numbers:
and for PyPI, it does not need pydev + Guido approval.
Disadvantages: none I can think of.
Someone mentioned cluttering namespace with 20-30 single char names. For readers, remembering what each letter means
(Some cleverness may be needed to have fractional scale values work with both floats and Decimals, but that shouldn't be hard.)
Make M, G, etc, instances of a class with def __mul__(self, other) that conditions on type of other.