[Python-ideas] SI scale factors alone, without units or dimensional analysis

[Terry Reedy]

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.

-- 
Terry Jan Reedy