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)
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.
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.
d. Many people objected to allowing the use of naked scale factors as
a perversion of the standard.
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?
-Ken
_______________________________________________
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
