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
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
