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