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