[Python-ideas] real numbers with SI scale factors: next steps

[Sven R. Kunze]

Thanks a lot for this comprehensive summary. :) Find my comments below.


On 30.08.2016 22:34, Ken Kundert wrote:
> Okay, let's try to wrap this up. In summary I proposed three things:
>
> 1. A change to the Python lexer to accept SI literal as an alternative, but not
>     replacement to, E-notation. As an optional feature, simple units could be
>     added to the end but would be largely ignored. So the following would be
>     accepted:
>
>        freq = 2.4GHz
>        r = 1k
>        l = 10nm
>
>     The idea in accepting units was to allow them to be specified when convenient
>     as additional documentation on the meaning of the number.
>
>     Objections:
>     a. Acceptance of the abbreviation for Exa (E) overlaps with E-notation (1E+1
>        could represent 1e18 + 1 or 10). A suggestion to change the prefix from
>        E to X conflicts with a proposal to use X, W, and V to represent 10^27,
>        10^30, and 10^33 (en.wikipedia.org/wiki/Metric_prefix)

I think this results from the possibility of omitting the SI units.

>     b. Allowing the units to be specified will lead some users to assume
>        a dimensional analysis is being performed when in fact the units are
>        ignored. This false sense of security could lead to bugs.

Same can be said for variable annotations for which a PEP is in the works.

>     c. The proposal only supports simple units, not compound units such as m/s.
>        So even if hooks were provided to allow access to the units to support an
>        add-on dimensional analysis capability, an additional mechanism would have
>        to be provided to support compound units.

I get the feeling that SI syntax should only work when the hook is provided.

So this could be the dealbreaker here: only enabling it when the hook is 
provided, changes the syntax/semantics of valid Python code depending on 
the presence of some hidden hooks. Enabling the syntax regardless of a 
working hook, have those sideeffects like described by you above.

So, no matter how done, it always has some negative connotation.

>     d. Many people objected to allowing the use of naked scale factors as
>        a perversion of the standard.

Remove this and it also solves 1.a.

>
> 2. A change to the float() function so that it accepts SI scale factors and
>     units. This extension naturally follows from the first: the float function
>     should accept anything the Python parser accepts.  For example:
>
>        freq = float('2.4GHz')
>        r = float('1k')
>        l = float('10nm')
>
>     Objections:
>     a. The Exa objection from the above proposal is problematic here as well.
>     b. Things that used to be errors are now no longer errors. This could cause
>        problems if a program was counting on float('1k') to be an error.
>
>
> 3. A change to the various string formatting mechanisms to allow outputting real
>     numbers with SI scale factors:
>
>        >>> print('Speed of light in a vacuum: {:r}m/s.'.format(2.9979e+08))
>        Speed of light in a vacuum: 299.79 Mm/s.
>
>        >>> print('Speed of sound in water: %rm/s.' % 1481
>        Speed of sound in water: 1.481 km/s.
>
>     Objections:
>     No objections were raised that I recall, however here is something else to
>     consider:
>
>     a. Should we also provide mechanism for the binary scale factors (Ki, Mi,
>        ..., Yi)? For example: '{:b}B'.format(2**30) --> 1 GiB.
>
> On proposed extension 1 (native support for SI literals) my conclusion is that
> we did not reach any sense of consensus and there was considerable opposition to
> my proposal.  There was much less discussion on extensions 2 & 3, so it is hard
> to say whether consensus was reached.
>
> So, given all this, I would like to make the following recommendations:
> 1. No action should be taken.
> 2. The main justification to modifying float() was to make it consistent with
>     the extended Python language. Without extension 1, this justification goes
>     away. However the need to be able to easily convert strings of numbers with
>     SI scale factors into floats still exists. This should be handled by adding
>     a library or extending an existing library.
> 3. Allowing numbers to be formatted with SI prefixes is useful and not
>     controversial. The 'r' and 'b' format codes should be added to the various
>     string formatting mechanisms.
>
> What do you think?

I like your conclusion. It seems there is missing some technical note of 
why this won't happen the way you proposed it (maybe the hook + missing 
stdlib package for SI units). :)

Aren't there some package already available for recommendation 3?


Sven