On Fri, Aug 26, 2016 at 07:35:36AM +0200, Pavol Lisy wrote: > On 8/25/16, Ken Kundert <python-id...@shalmirane.com> wrote: > > [...] > > > Just allowing the units to be present, even it not > > > > retained, is a big advantage because it can bring a great deal of clarity to > > the > > meaning of the number. For example, even if the language does not flag an > > error > > when a user writes: > > > > vdiff = 1mV - 30uA > > It reminds me: "Metric mishap caused loss of NASA's Mars Climate > orbiter. It could be nice to have language support helping to avoid > something similar.
This proposal won't help to avoid this sort of disasterous misuse of units. It will make that sort of mistake *easier*, not harder, by giving the user the false sense of security. A good description of the Mars Orbiter mishape can be found here, with a link to the NASA report: http://pint.readthedocs.io/en/0.7.2/ Suppose I am programming the Mars lander. I read in some thruster data, in pound-force seconds: thrust = sm_forces(arg) # say, it returns 100 lbf·s I don't expect to see the tag "lbf·s" anywhere unless I explicitly print the value out or view it in a debugger. So the tag gives me no visual assistence in avoiding unit conversion bugs. It is worse than having no unit attached at all, because now I have the false sense of security that it is tagged with a unit. Much later on I pass that to a function that expects the thrust to be in Newton seconds: result = fire_engines(thrust) There's no dimensional analysis, so I could just as easily pass 100 kilograms per second cubed, or 100 volts. I have no protection from passing wrong units. But let's ignore that possibility, and trust that I do actually pass a thrust rather than something completely different. The original poster Ken has said that he doesn't want to do unit conversions. So I pass a measurement in pound force seconds, which is compatible with Newton seconds, and quite happily use 100 lbf·s as if it were 100 N·s. End result: a repeat of the original Mars lander debacle, when my lander crashes directly into the surface of Mars, due to a failure to convert units. This could have been avoided if I had used a real units package that applied the conversion factor 1 lbf·s = 44.5 N·s, but Kevin's suggestion won't prevent that. You can't avoid bugs caused by using the wrong units by just labelling values with a unit. You actually have to convert from the wrong units to the right units, something this proposal avoids. I think that Ken is misled by his experience in one narrow field, circuit design, where everyone uses precisely the same SI units and there are no conversions needed. This is a field where people can drop dimensions because everyone understands what you mean to say that a current equals a voltage. But in the wider world, that's disasterous. Take v = s/t (velocity equals distance over time). If I write v = s because it is implicitly understood that the time t is "one": s = 100 miles v = s Should v be understood as 100 miles per hour or 100 miles per second or 100 miles per year? That sort of ambiguity doesn't come up in circuit design, but it is common elsewhere. -- 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/