> The trouble is that SI isn't the only set of units out there. And > particularly if you support SI derived units, there will be > innumerable collisions of abbreviations with other systems. Unless > you're going to mandate *in the language* that SI units are the only > ones permitted (and thus anger a fairly large slab of people), the > precise meanings of the abbreviations will have to be handled by > libraries.
Mentioned in another part of the thread, but if you wanted to be completely comprehensive, including measures used for cooking, you would *only* need 160 units. But if you want to focus on where you make an impact - that is, units that are used in computations and dimensional analysis (i.e. - not teaspoons), 7-14 units is a good start. That's the 7 base units and their Imperial / US Customary counterparts. Literally every other unit of measurement can be derived from these. After that, ~50 units is pretty fantastic, and by the time you get to 100 units, there might be 1 or 2 people who feel left out, but they're probably not going to be angry about it. > Oh absolutely they should be available for integers. Unfortunately, > that doesn't always solve the problem. Exactly how far is it from the > sun to Saturn at aphelion? Do you write it as 1357554000000m, which > implies false precision? What about 1.357554e12m ? Well, that's a > float, not an int. (My apologies if the figure is straight-up wrong, I > just pulled that from a quick Google search.) It's pretty much > inevitable that floats are going to show up, and that means that > forcing everything into the same scale system is likely to cause > problems (just like when you're building a 3D graphical world and you > place a light source 1AU away to represent sunlight - you just create > unnecessary FP inaccuracies). A standard unit of measure has infinite precision. If the distance from the sun to Saturn at aphelion does not have infinite precision, then it cannot be a unit. It's definitely not a standard unit. If you want to define it as a unit, then I guess you have to pinch your nose and claim that it has infinite precision? I totally agree that you need to be able to use units at the correct scale. But a unit *must* have infinite precision. It might make more sense to define an arbitrary unit called the AsirhC as 1.357554e12m (with infinite precision), and you would be doing so because that is the distance that you believe the sun to Saturn at aphelion is, but once defined in that way, you shouldn't worry about how far off it is. > I would say that 2.54in/1cm should be equal to 1. Units should > completely cancel out. It's less clear when there's choice of > equivalent units, like "5ft+6in" potentially being "5.5ft" or "66in"; > but I would also say that those two quantities should compare equal. > (Which may make their hashes tricky to calculate.) Easy answer: whichever unit results in the floating point portion of the data type being closest to 0. It only matters at the point in time when the answer is presented to the end user anyway, at which point best practice would say to use an explicit cast. > Where would "measure SI" be implemented? Does it have to be a core > feature of the language? The global statement (there's no "local" > statement - do you mean "nonlocal"?) is fully defined by the language, > so its impact on the surrounding code is also well defined. But if > "measure" statements can be provided by importable modules, there are > only two options: either it's a run-time action (like most imports), > or it has to be done before you import something else, which requires > a bootstrap script: Yes, I mean "nonlocal". In my example the "measure" statement would be a core part of the language. Which, as I said in my original soapbox post, is what I would ideally like to see change. "Every number has a unit" sounds crazy until you get used to it, and its a level of crazy that requires a core language change. Current library implementations have so far failed to gain much traction. Better implementations *might* work without changing the language? Tbh, I really don't know. To elaborate further on what I mean by my proposed "measure" statement, it would need to be supported by core language. The very first block of parser code that would act on this statement would in fact sit right next to the code that currently handles "global" and "nonlocal" and would look very similar. Once the "measure" statement is encountered, the state of the parser itself is altered. I'm not sure if this happens at all in the parser today, but after executing the "measure" statement, literals like "12m" would suddenly become legal, by virtue of the parser loading or enabling a set of additional parsing rules. Sort of like a dynamic parser. Your approach would be great, btw, I just don't quite see how the string literal gets into the library. But I likewise will keep an open mind on it. Another possibility is to make floats and ints "subscriptable". The reason is, it is not unusual to see units enclosed in brackets. Like this: 12[m] 12[m/s] 100[cd/m2] # Or 100[cd/m**2]? In that case, the parser does not need to be dynamic. m in this case could be interpreted as a variable name, which would be registered, as you say. But I would strongly argue in favor of a separate namespace for objects within an integer or float subscript. "12[SI.m]" is ugly, especially when you start getting into complex units. Not to mention, lots of scientists and engineers are allergic to dot-notation (I know, why even bother, but I'm a people pleaser). Similarly, ruling out "m" as a variable name is a non-starter. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/AZMBKOMUYGVEYUMZZBLQITXG5LCHFMHY/ Code of Conduct: http://python.org/psf/codeofconduct/
