[Python-ideas] SI scale factors in Python

Steven D'Aprano steve at pearwood.info
Thu Aug 25 07:24:05 EDT 2016


On Wed, Aug 24, 2016 at 09:28:03PM -0700, Ken Kundert wrote:
> All,
>     I propose that support for SI scale factors be added to Python.

I think there's something to be said for these ideas, but you are 
combining multiple ideas into one suggestion.

First off, units with quantities: I think that is an excellent idea, but 
one best supported by a proper unit library that supports more than just 
SI units. There are already a few of those. See for example this 
Stackoverflow question:

http://stackoverflow.com/questions/2125076/unit-conversion-in-python

Sympy also does dimensional analysis:

http://docs.sympy.org/latest/modules/physics/unitsystems/examples.html

Google for more.

If I try to add 30 feet to 6 metres and get either 36 feet or 36 metres, 
then your unit system is *worse* than useless, it is actively harmful. I 
don't mind if I get 15.144 metres or 49.685039 feet or even 
5.0514947e-08 lightseconds, but I better not get 36 of anything.

And likewise for adding 30 kilograms to 6 metres. That has to be an 
error, or this system will just be an attractive nuisance, luring people 
into a false sense of security while actually not protecting them from 
dimensional and unit conversion bugs at all.

So I am an extremely strong -1 to the suggestion that we allow unit 
suffixes on numeric quantities but treat them as a no-op.

Should Python support a unit conversion library in the standard library? 
I think perhaps not -- there's plenty of competition in the unit 
conversion ecosystem, both in Python and out of it, and I don't think 
that there's any one library that is both sufficiently "best of breed" 
enough and stable enough to put into the std lib. Remember that the std 
lib is where good libraries go to die: once they hit the std lib, 
stability becomes much, much more important than new features.

But if you wish to argue differently, I'll be willing to hear your 
suggestions.

Now, on to the second part of the suggestion: support for SI prefixes. I 
think this is simple enough, and useful enough, that we could make it 
part of the std lib -- and possibly even in 3.6 (possibly under a 
provisional basis). The library could be dead simple:

# prefixes.py
# Usage:
# from prefixes import *
# x = 123*M  # like 123000000
# y = 45*Ki  # like 45*1024

# SI unit prefixes
# http://physics.nist.gov/cuu/Units/prefixes.html
Y = yotta = 10**24
Z = zetta = 10**21
[...]
k = kilo = 10**3
K = k  # not strictly an SI prefix, but common enough to allow it
m = milli = 1e-3
µ = micro = 1e-6  # A minor PEP-8 violation, but (I hope) forgiveable.
u = µ  # not really an SI prefix, but very common
# etc


# International Electrotechnical Commission (IEC) binary prefixes
# http://physics.nist.gov/cuu/Units/binary.html
Ki = kibi = 1024
Mi = mibi = 1024**2
Gi = 1024**3
# etc


That's practically it.

Of course, this simple implementation would allow usage that was a 
technical violation of the SI system:

x = 45*M*µ*Ki

as well as usage that is semantically meaningless:

x = 45 + M

but those abuses are best covered by "consenting adults". (In other 
words, if you don't like it, don't do it.) And it wouldn't support the 
obsolete binary prefixes that use SI symbols with binary values (K=1024, 
M=1024**2, etc), but that's a good thing. They're an abomination that 
need to die as soon as possible.



-- 
Steve


More information about the Python-ideas mailing list