[Python-ideas] real numbers with SI scale factors

[Steven D'Aprano]

On Mon, Aug 29, 2016 at 04:24:42PM -0700, Ken Kundert wrote:
> > [...]
> >    Her comment: I did not write it for him.
> > [...]
> 
> It has been pointed out to me that the above comes off as being condescending 
> towards Steven, system administrators and language developers in general. For 
> this I am profoundly sorry. It was not my intent. My only point was that the 
> output of these numerical programs are often so highly specialized that only the 
> authors and their peers understand it.

No offense taken Ken! I completely understand what your astrophysicist 
friend means, and I don't expect that she should write code for me.

But we have to consider code written for her, and me, and you, and 
system administrators, children learning their first language, Java 
gurus, Haskell experts, people whose only other language was BASIC in 
1980, animators, scientists, web developers, and many, many other 
disparate groups of people. We have to do it without breaking 
backwards compatibility. And some how we have to try to balance all 
those different needs without compromising the essential "Pythonicity" 
of the language.

The culture of Python is very conservative. I don't know of any features 
in Python that haven't come from some other language. Sometimes, like 
significant indentation, it was only a single language at the time that 
Python copied the feature. Sometimes a feature is not accepted unless it 
is in widespread use. It's a good sign that unit tracking is (slowly) 
becoming a language feature, like in F#, but I think you doomed your 
proposal as soon as you said (paraphrasing) "no other language does 
this, Python should lead the way and blaze this trail".

(That's actually not the case, but when the prior art is niche languages 
like F# and Frink and calculator languages like RPL, it was always going 
to be a tough sell.)

Sometimes it just means that the time is not right for a new feature. 
The ternary if operator was resisted for many years until a compelling 
reason to add it was found, then it was accepted rapidly.

Maybe the time will never be right: nearly everyone agrees that there is 
no reason to actively avoid having multi-statement anonymous lambda 
functions, if only we can find the right syntax. But nobody has found 
the right syntax that isn't ambiguous, or goes against the style of 
Python, or requires changes to the parser that are unacceptible for 
other reasons.

Personally, I think that your proposal has a lot of merit, it's just the 
details that I don't like. Absent an excellent reason why it MUST be a 
language feature, it should stay in libraries, where people are free to 
experiment more freely, or projects like IPython and Sage, that can 
explore their own interactive interpreters that can add new features 
that Python the language can't.

And maybe, in Python 3.7 or 3.9 or 4.9, somebody will come up with the 
right proposal, or the right syntax, or notice that (let's imagine) 
Javascript or C++ has done it and the world didn't end, and Python will 
get unit tracking and/or multiplicative scaling factors as a language 
feature and you'll be vindicated.

Personally, I hope it does. But it has to be done right, and I'm not 
convinced your proposal is the right way. So until then, I'm happy to 
stick to it being in libraries.

But most importantly, thanks for caring about this!

-- 
Steve