[Python-ideas] SI scale factors in Python

Nick Coghlan ncoghlan at gmail.com
Fri Aug 26 01:34:03 EDT 2016


On 26 August 2016 at 13:46, Ken Kundert <python-ideas at shalmirane.com> wrote:
> On Fri, Aug 26, 2016 at 10:14:53AM +1000, Steven D'Aprano wrote:
>> On Thu, Aug 25, 2016 at 11:02:11AM -0700, Ken Kundert wrote:
>>
>> > Even if the language completely ignores the units, we have still gained by
>> > allowing the units to be there, just like we gain when we allow user to add
>> > comments to their code even though the compiler ignores them.
>>
>> This part of your proposal would be *worse*: you would fool the casual or
>> naive user into believing that Python did dimensional analysis, while in fact
>> not doing so. You would give them a false sense of security.
>
> This idea is new to general purpose languages, but it has been used for over 40
> years in the circuit design community. Specifically, SPICE, an extremely heavily
> used circuit simulation package, introduced this concept in 1974. In SPICE the
> scale factor is honored but any thing after the scale factor is ignored.  Being
> both a heavy user and developer of SPICE, I can tell you that in all that time
> this issue has never come up. In fact, the users never expected there to be any
> support for dimensional analysis, nor did they request it.

[snip]

> And it has little to do with my proposal, which is basically this:
>
> Numbers with SI scale factor and units have become very popular. Using them is
> a very common way of expressing either large or small numbers. And that is true
> in the scientific and engineering communities, in the programming community
> (even the linux sort command supports sorting on numbers with SI scale factors:
> --human-numeric-sort), and even in popular culture.
>
> Python should support them. And I mean support with a capital S. I can come up
> with many different hacks to support these ideas in Python today, and I have.
> But this should not be a hack. This should be built into the language front and
> center. It should be the preferred way that we specify and output real numbers.

Thanks for the additional background Ken - that does start to build a
much more compelling case.

I now think there's another analogy you'll be able to draw on to make
it even more compelling at a language design level: just because the
*runtime* doesn't do dimensional analysis on static unit annotations
doesn't mean that sufficiently clever static analysers couldn't do so
at some point in the future. That then puts this proposal squarely in
the same category as function annotations and gradual typing: semantic
annotations that more clearly expressed developer intent, and aren't
checked at runtime, but can be checked by a human during code review,
and (optionally) by static analysers as a quality gate.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list