<p dir="ltr">I teach working scientists about numeric computing on a daily basis. There are a few special field where Ken's ideas are the norm, at least in informal notation. The large majority of working scientists would find a syntax change like he proposes an annoyance and nuisance.</p>
<p dir="ltr">Alienating and confusing everyone who isn't a circuit designer is a bad goal. It's not going to happen in python.</p>
<p dir="ltr">If you really want this syntax, you need to use a different language, or maybe write a preprocessor that turns a slightly different language back into Python.</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Aug 29, 2016 4:09 AM, "Ken Kundert" <<a href="mailto:python-ideas@shalmirane.com">python-ideas@shalmirane.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> > These do not seem like good reasons for not doing this.<br>
><br>
> Not worded the way you have them, no, because you've aimed for an<br>
> extremely emotional argument instead of answering concrete questions<br>
> like "where's the code that this would improve". Find some real-world<br>
> code that would truly benefit from this. Show us how it's better.<br>
<br>
Sorry, I am trying very hard not to let my emotions show through, and instead<br>
provide answers, examples, and comments that are well reasoned and well<br>
supported. I do find it frustrating that I appear to be the only one involved in<br>
the conversation that has a strong background in numerical computation, meaning<br>
that I have to carry one side of the argument without any support. It is<br>
especially frustrating when that background is used as a reason to discount my<br>
position. Let me try to make the case in an unemotional way.<br>
<br>
It is hard to justify the need for SI scale factors being built into the<br>
language with an example because it is relatively simple to do the conversion.<br>
For example ...<br>
<br>
With built-in support for SI scale factors:<br>
<br>
h_line = 1.4204GHz<br>
print('hline = {:r}Hz'.format(h_line))<br>
...<br>
<br>
In Python today:<br>
<br>
from engfmt import Quantity<br>
h_line = Quantity('1.4204GHz')<br>
print('hline = {:q}'.format(h_line))<br>
h_line = float(h_line)<br>
...<br>
<br>
Not really much harder to use the library. This is very similar to the situation<br>
with octal numbers ...<br>
<br>
With built-in support for octal numbers:<br>
<br>
S_IFREG = 0o100000 # regular file<br>
<br>
With out built-in support for octal numbers:<br>
<br>
S_IFREG = int('100000', base=8) # regular file<br>
<br>
So just giving a simple example is not enough to see the importance of native<br>
support. The problem with using a library is that you always have to convert<br>
from SI scale factors as the number is input and then converting back as the<br>
number is output. So you can spend a fair amount of effort converting too and<br>
from representations that support SI scale factors. Not a big deal if there is<br>
only a few, but can be burdensome if there is a large number. But the real<br>
benefit to building it in a native capability is that it puts pressure on the<br>
rest of the ecosystem to also adopt the new way of representing real numbers.<br>
For example, now the interchange packages and formats (Pickle, YaML, etc.) need<br>
to come up with a way of passing the information without losing its essential<br>
character. This in turn puts pressure on other languages to follow suit. It<br>
would also put pressure on documenting and formatting packages, such as Sphinx,<br>
Jinja, and matplotlib, to adapt. Now it becomes easier to generate clean<br>
documentation. Also the interactive environments, such as ipython, need to<br>
adapt. The more this occurs, the better life gets for scientists and engineers.<br>
<br>
<br>
> Something that I don't think you've acknowledged is that the SI<br>
> scaling markers are *prefixes to units*, not *suffixes to numbers*.<br>
> That is to say, you don't have "132G" of a thing called a "pascal",<br>
> you have "132" of a thing called a "gigapascal". Outside of a<br>
> unit-based system, SI prefixes don't really have meaning. I don't<br>
> remember ever, in a scientific context, seeing a coefficient of<br>
> friction listed as "30 milli-something"; it's always "0.03". So if<br>
> unitless values are simply numbers, and Python's ints and floats are<br>
> unitless, they won't see much benefit from prefixes-on-nothing.<br>
<br>
Yeah, this is why I suggested that we support the ability for users to specify<br>
units with the numbers, but it is not a hard and fast rule. Once you add support<br>
for SI scale factors, people find them so convenient that they tend to use them<br>
whether they are units or not. For example, it is common for circuit designers<br>
to specify the gain of an amplifier using SI scale factors even though gain is<br>
often unitless. For example, gain=50k. Also, electrical engineers will often<br>
drop the units when they are obvious, especially if they are long. For example,<br>
it is common to see a resistance specified as 100k. When values are given in<br>
a table and all the values in a column have the same units, it is common to give<br>
numbers with scale factors by without units to save space.<br>
<br>
-Ken<br>
______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
</blockquote></div></div>