On Sun, Apr 3, 2022, 6:27 PM Chris Angelico <rosuav@gmail.com> wrote: On Mon, 4 Apr 2022 at 07:45, Ethan Furman <ethan@stoneleaf.us> wrote:

Mechanically, are `lbs`, `km`, `hr`, etc., something that is imported, or are they tags attached to the numbers? If attached to the numbers, memory size would increase and performance might decrease -- but, how often do we have a number that is truly without a unit?

How old are you? 35 years How much do you weigh? 300 kg What temperature do you cook bread at? 350 F

Very frequently - it'd be called an index. (What sort of numbers should enumerate() return, for instance? Clearly that, whatever it is, is an index.) But if every int and float has a tag attached to it, it's not that big a deal to have either a default tag, or leave the field NULL or None, to define it to be a unitless value or index. ChrisA How much memory would have to be added to every number? Could it be dynamically sized so it doesn't have a large impact on all the code out there with no units? But also grow to be big enough to capture the vast constellation of units and unit combinations out there? I'm unsure simple tags are enough. What should the behavior of this be? height = 5ft + 4.5in Surely we ought to be able to add these values. But what should the resulting tag be? Should we be able to write it like this? height = 5ft 4.5in I was cheerleading this effort earlier and I still think it would be a massive contribution to needs of the engineering world to solve this problem at the language level. But boy howdy is it a tough but of a problem to crack.

On Sun, Apr 3, 2022, 11:03 PM Chris Angelico <rosuav@gmail.com> wrote:

...

I'm unsure simple tags are enough. What should the behavior of this be?

...

height = 5ft + 4.5in

My view on this is that it should basically be defined as:

height = ft(5) + in(4.5)

where you register your constructor functions (possibly types, possibly factory functions) using a hook in the sys module.

This is really similar to what pint does already (except it uses the multiplication syntax if course). What does that idea bring other than being able to say: 5.0m (m registered in a previously run module) .... instead of: 5.0*m (m an object imported in a previously run module) ?

Surely we ought to be able to add these values. But what should the resulting tag be? Should we be able to write it like this?

...

height = 5ft 4.5in

That, I would say, no. There are a lot of human-readable notations that aren't supported by programming languages, such as algebraic "abuttal means multiplication" and such. It's not that hard to say "5ft + 4.5in", just like you'd say "3 + 4j" for a complex number.

Makes sense to me. (Also, I don't really see a lot of point in making feet-and-inches

minorly less complicated, given that people should be trying to use metric anyway.)

They're almost all I use professionally. I graduated college in 2010 and have almost never used centimeters or millimeters since then. "Shoulds" aside, feet and inches are not going away and any unit system needs to make them first class and easy to use or it will be extremely painful for large chunks of progressional engineers. But 5ft+4in is fine.

I was cheerleading this effort earlier and I still think it would be a massive contribution to needs of the engineering world to solve this problem at the language level. But boy howdy is it a tough but of a problem to crack.

...

This is something where (again, my view only, others may disagree) the language itself need not actually make a decision. Ideally, the standard library should have something usable, but it should be such that you could choose to do something else. The standard library could even have more than one unit system in it - for instance, you could have a metric-focused system that converts "5ft" into "1.524m", or you could have a unit-retaining system that keeps everything in the unit specified until such time as conversions are needed, etc.

Yup, being able to choose to retain units or convert them to preferred units is important. One very important feature for the standard library would be a generic

"Quantity" type, which could save a lot of hassle. You could create a "length" quantity and register a number of units, and define that any length can be added to any other length, a length can be multiplied by a scalar, etc, etc, etc. Then a bit of generic handling could also recognize that when you multiply or divide two quantities, you get something in a combined unit (whether that's "length*length" meaning area, or "length/time" meaning velocity), and libraries could slot in whatever units make the most sense. Maybe you're working with astronomical distances, and the meter just causes too many floating-point roundoff errors, so you define your base unit to be the parsec, and everything else derives from that. Or maybe you're working with video game analysis and the most important quantity is "items per minute" (eg 780 iron ore per minute), so you define each type of item as its own quantity, and redefine time with a basis of minutes instead of seconds. Having the tools to do that is probably more important than defining it all at the language level.

I like and think I understand most of what you're saying here. I think much of this has been thought through and solved by the pint library, and some others. Having a "slot" to natively associate a unit tag with numerical values, and syntax support with defined semantics, could be a big win. Leaving the "now let's make decisions about behavior" part to 3rd parties makes sense to me. But what superpower does bringing the notion of tagging things into the native language bring for us if all the tag does is call a function that returns a thing? It almost just sounds like a postfix function call syntax to me.

Typing "3m + 4cm" into a terminal produced the above output, even if it meant I needed to import the pint module, that would be great. No idea how that would work out, but all for it. argparse still seems like it would be a loose end, though. Although, to be fair, it would be a loose end no matter what.

I think I posted this somewhere else in this thread, or the previous thread. argparse can handle negative numbers, but only of one of the built-in primitive types. See example below: ``` import re, argparse class meters(float): def __new__(cls, x): return super().__new__(cls, float(re.sub(r'm','',x))) parser = argparse.ArgumentParser() parser.add_argument("-l", "--length", dest='length', type=meters) # _StoreAction(option_strings=['-l', '--length'], dest='length', nargs=None, const=None, default=None, type=<class '__main__.meters'>, choices=None, help=None, metavar=None) meters("12") #12.0 meters("12m") #12.0 parser.parse_args("-l -12".split()) #Namespace(length=-12.0) parser.parse_args("-l -12m".split()) #usage: [-h] [-l LENGTH] #: error: argument -l/--length: expected one argument ```

The C++ way is custom literals (it's where this thread originated) https://mail.python.org/archives/list/python-ideas@python.org/thread/MFZ52D3... One problem I am seeing is a misunderstanding between standard, well-defined units, and technical lingo - for which I am not advocating native language support. Also, standard units here does not mean universal constants. There is no reason or need to provide any kind of new language support for those. The problem as described in my original post (rant?) is that without units, any computational code is less WYSIWYG. C++ has a way to deal with units in literal expressions, why not Python? And no, language support alone is not enough, since NumPy and SciPy would have to add code to implement as well, and then there is data entry (command line arguments, config files, web forms, etc.). Native language support is not a magic bullet, but it is a bullet.

The register_numeric_suffix idea would create a true global namespace, independent of the module system. That seems like a bad idea: libraries should be able to use their own units internally without potentially breaking other libraries. Units should be local to each module. You need a way to import them into your module's unit namespace. You might want to import only some of the units exported by a unit provider...

The reason I disagree with this view is that units of measurement are fixed. I'm sure that when I say this, some will be reminded of trauma that they have experienced with "datetime" objects and UTC jujitsu, but those are not the same. Units of measure are immutable, and have only one proper meaning. PEP 20 says "There should be one-- and preferably only one --obvious way to do it. [sic]" Seems like that should apply to units as well. In fact, for mechanical engineering software packages like SolidWorks there already is a standard for unit conversions: https://en.wikipedia.org/wiki/Unified_Code_for_Units_of_Measure

On 4/04/22 7:59 pm, Chris Angelico wrote:

How often do you ACTUALLY need them to be local to a module? When is this ever a concern?

As long as there are competing *implementations* of units there will be potential for conflicts, even if the actual units being represented are the same. -- Greg

On 2022-04-04 01:19:13, python@shalmirane.com wrote:

This implies that it is only necessary to provide a package for reading and writing physical quantities, and indeed such a package exists: QuantiPhy. QuantiPhy came out of the ideas that were raised the last time this topic was discussed on this mailing list a few years ago.

Link for the curious, IMHO seems to solve most of the objections raised here without language-level changes: https://pypi.org/project/quantiphy/ https://pypi.org/project/quantiphy-eval/ I wish I knew this existed when I re-implemented part of this (with bugs) a while back.

As why it is naive, see my previous post where I talk about the limitations of dimensional analysis. As a point of reference, I have been developing software for electrical engineers for over 40 years. That software uses physical quantities (voltage current, resistance, capacitance, etc.) heavily. Over those 40 years I have written and rewritten units packages maybe a half-dozen times. In that time I have never seriously considered writing a dimensional analysis based units package. In general, dimensional analysis is something you do once, not every time the program runs. As for links to the previous discussion, search for “SI scale factors”. The discussion occurred 5 years ago. -Ken On Mon, Apr 04, 2022 at 03:06:26PM -0000, Brian McCall wrote:

...

Much of this discussion is based on a misconception. Units and SI scale factors are very useful in software that describes or interacts with the real world, but primarily on input and output. They are not normally used for internal calculations. The idea that one carries units on variables interior to a program, and that those units are checked for all interior calculations, is naive. Doing such thing adds unnecessary and often undesired complexity. Rather, it is generally only desirable to allow users to include scale factors and units on values they specify and values they read. This implies that it is only necessary to provide a package for reading and writing physical quantities, and indeed such a package exists: QuantiPhy. QuantiPhy came out of the ideas that were raised the last time this topic was discussed on this mailing list a few years ago.

Why is it naive to carry the units through calculation? Seems to me that a one-byte lookup and a 64-bit add/subtract would be enough to enable any plausible combination of standard units during computation. The conversion from raw powers of 7 base SI units to units of choice could be done at a higher level code at the input/output stage.

QuantiPhy is definitely not what I am thinking of. You don't happen to have a subject line for the previous discussion that I can look up, do you? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/PL3UHV... Code of Conduct: http://python.org/psf/codeofconduct/

On Mon, 2022-04-04 at 09:14 -0700, Ken Kundert wrote:

As why it is naive, see my previous post where I talk about the limitations of dimensional analysis.

As a point of reference, I have been developing software for electrical engineers for over 40 years.  That software uses physical quantities (voltage current, resistance, capacitance, etc.) heavily.  Over those 40 years I have written and rewritten units packages maybe a half-dozen times.  In that time I have never seriously considered

Are there any Python or e.g. C/C++ libraries that may be useful to wrap for Python that are open source? There is interest in making units available to NumPy through a DType directly on the NumPy array. I.e. not quite the same way as `astropy.units` or `pint`, but rather ingraining deeper into NumPy (but written outside). And it would be great to have a full featured units library as a basis for this.

writing a dimensional analysis based units package.  In general, dimensional analysis is something you do once, not every time the program runs.

I would say it actually is often something you are happy to do every time the program runs. If you think about NumPy (like) usage, there are at least two use-cases: 1. You have a mid-to large sized amount of data. Figuring out units probably just doesn't matter performance wise. 2. You don't care about performance anyway, but rather about flexibility in your analysis workflow. Now, libraries may often need to strip units for more performance. That is, for example while running machine-learning algorithm or an integration, etc. But, I think it is fair to say that often reversing the approach may well be good: Use units by default, but strip them for performance. I can understand the idea of a (soft) "literal operator", i.e. so that it is possible to write: from units import cm, s length = 1.8_cm speed = length / 3_s And it would use `cm.__from_literal__("1.8", kind="floating")`. Of course that could be incompatible with other unit providing libraries (unless they agree on some ABC). I assume this is what C++ does? I am unsure that "tagging" in itself is helpful. What will: 1.3_m / 2_s give you? A `TaggedFloat(1.3, "m")` object may work. But can such a naïve units even propagate clearly enough that it can be reasonably implemented in a generic way? (Unless there is a blessed standard library units implementation at least.) Cheers, Sebastian

As for links to the previous discussion, search for “SI scale factors”.  The discussion occurred 5 years ago.

-Ken

On Mon, Apr 04, 2022 at 03:06:26PM -0000, Brian McCall wrote:

...

...

Much of this discussion is based on a misconception.  Units and SI scale factors are very useful in software that describes or interacts with the real world, but primarily on input and output.  They are not normally used for internal calculations.  The idea that one carries units on variables interior to a program, and that those units are checked for all interior calculations, is naive.  Doing such thing adds unnecessary and often undesired complexity.  Rather, it is generally only desirable to allow users to include scale factors and units on values they specify and values they read.  This implies that it is only necessary to provide a package for reading and writing physical quantities, and indeed such a package exists: QuantiPhy.  QuantiPhy came out of the ideas that were raised the last time this topic was discussed on this mailing list a few years ago.

Why is it naive to carry the units through calculation? Seems to me that a one-byte lookup and a 64-bit add/subtract would be enough to enable any plausible combination of standard units during computation. The conversion from raw powers of 7 base SI units to units of choice could be done at a higher level code at the input/output stage.

QuantiPhy is definitely not what I am thinking of. You don't happen to have a subject line for the previous discussion that I can look up, do you? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/PL3UHV... Code of Conduct: http://python.org/psf/codeofconduct/

---

Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/NYVZME... Code of Conduct: http://python.org/psf/codeofconduct/

Just to elaborate on units I use, here's a hypothetical (not stuff that actually happened today, but very commonplace nature): I drove 20 minutes up the road to by a bushel (US, not British) of U.S. No.

1. apples, to make apple cider. On my return trip, I stopped at the hardware store to buy a 2 lb box of 1-3/4" ring shank 12 penny nails. I used my 7/8 hole kitchen planer blade to grate the apples, then squeezed them for an hour and a 15 minutes at 30 psi to extract the juice. For good measure I added 2 tablespoons of vanilla and a pinch of salt. Then I drove the nails into grade C 2x4 joists (whose sizes are 1.5 x 3.5 inches, with a 1/16th inch permissible tolerance in sizing).

Please express that description in SI units! ;-) On Mon, Apr 4, 2022 at 11:55 AM Ken Kundert <python@shalmirane.com> wrote:

I think there is one more point worth making here. There is a suggestion that dimensional analysis can underpin a units system. Actually, the idea that all units can be broken down into a small set of fundamental units is very limiting and results in many vexing issues.

For example, consider currencies. There are currently hundreds of national currencies and thousands of cryptocurrencies. They all have the same basic fundamental unit of “value”, but value is only loosely defined. Furthermore, there is no fixed ratio between the currency and its value. It varies over time, over location, and from person to person.

Consider units of a particular commodity. The example of a ream of paper was recently mentioned. A ream is 500 sheets of paper. However two reams may not be comparable. They may refer to a different size of paper or a different quality of paper. So all prices for reams of paper would have the same fundamental units of “value per each”, but both “value” and “each” are not necessarily comparable. In effect, the fundamental unit system is not complete. You also need to include information about what you are measuring. For example, “each” could represent a single item of anything. The unit is not complete until you include a description of what that anything is, and in effect, there is an unlimited number of things it could be.

Now consider the issue of “unitless units”. In electrical circuit we often talk about gain, which it the ratio between the signal level at the output of a circuit relative to the signal level at the input. But you need to be specific about how you measure signal level. Typically, it would be a voltage, current, or power level. Consider a circuit where both the input and output are measured in volts. Then the gain would have units of "V/V", which is unitless in dimensional analysis. But units of "V/V" (voltage gain) is much different from units of "A/A" (current gain) or "W/W" (power gain), even though they have the same dimensions. Mixing them up results in errors and confusion. An additional complication is that sometimes logarithmic units are used. For example, decibels in voltage, or dBV, is 20*log(Vout/Vin). Again, a dimensionless quantity, but nonetheless "dBV" much different from "V/V".

The same issue occurs with the arguments to trigonometric functions like sin(), cos() and tan(). Generally, we assume the arguments are given in radians, which is a dimensionless number. But it could also be given in degrees, another dimensionless number. Radians and degrees are indistinguishable from the perspective on dimensional analysis, but mixing them up results in errors.

This is not to knock the idea of dimensional analysis. It is just not something that would be done in most programs that process physical quantities. Rather it is something that is largely done as a one-time check on your analysis. It is a “second opinion” on whether your hand calculation are correct, or at least plausible. So dimensional analysis packages such as pint have their place, but dimensional analysis is not something that belongs in the base language or even the standard library.

However I do believe that a case can be made to allow numbers to be easily tagged with units in the base language, and then allowing those units to be accessed as an attribute of the number. Packages such as pint and QuantiPhy could then use that attribute to provide processing of units that is appropriate for the particular application.

-Ken _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/A6BVGO... Code of Conduct: http://python.org/psf/codeofconduct/

-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.

On Mon, Apr 04, 2022 at 05:45:52PM -0000, Brian McCall wrote:

Anyway, you mentioned you knew of at least 1000 units. I count 7. You have another 993?

Will 2451 do? [steve@ando ~]$ units 2438 units, 71 prefixes, 32 nonlinear units -- Steve

You should probably change the thread subject to "All-and-only 7 SI units" if that's what you mean. On Mon, Apr 4, 2022 at 1:46 PM Brian McCall <brian.patrick.mccall@gmail.com> wrote:

...

I drove 20 minutes up the road to by a bushel (US, not British) of U.S. No. 1. apples, to make apple cider. On my return trip, I stopped at the hardware store to buy a 2 lb box of 1-3/4" ring shank 12 penny nails. I used my 7/8 hole kitchen planer blade to grate the apples, then squeezed them for an hour and a 15 minutes at 30 psi to extract the juice. For good measure I added 2 tablespoons of vanilla and a pinch of salt. Then I drove the nails into grade C 2x4 joists (whose sizes are 1.5 x 3.5 inches, with a 1/16th inch permissible tolerance in sizing).

I'm going to start by ignoring any quantities above that are not involved in any sort of calculation. Those are outside the scope of the problem and proposal. And I don't care what anyone thinks of that.

The only calculation I see here is 1.5 in x 3.5 in = 0.00339 mm2. The fact that joists are called 2x4 even though their nominal dimension is 1.5 in x 3.5 in is also outside the scope of the problem and proposal. Come on man, you think you're the only one who knows examples like this? How about 1/3" image sensors? How about display diagonals? I know about these things, and I know that they do not need to be accounted for in a standard, language-supported representation of units.

Units have infinite precision, so grades and tolerances are also irrelevant.

The units you mentioned are: minutes bushel (imperial) bushel (US) psi tablespoon pinch (it's a stretch, but okay) foot inch

7/8 hole - this is a specification, not a unit 2x4 joist - specification, not a unit grade C - specification, not a unit 12 penny - Wikipedia calls it a unit, but calculations in measurements taken in units of pennies are neither associative nor distributive, and transformations on measurements taken in units of pennies are neither additive nor multiplicative.

Anyway, you mentioned you knew of at least 1000 units. I count 7. You have another 993? _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/DHRG6S... Code of Conduct: http://python.org/psf/codeofconduct/

-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.

On Mon, Apr 04, 2022 at 04:44:58PM -0700, Ethan Furman wrote:

Beyond that, do we make Python smart enough to, for example, convert `km*km` to `km^2`, or do we let libraries provide their own functions? I'm inclined to let libraries provide their own, as they could also implement unit conversions as desired.

There already are libraries for units in Python: https://pypi.org/project/units/ https://pypi.org/project/quantities/ https://pypi.org/project/Unum/ https://pypi.org/project/Pint/ It would be kind of nice if there was a little less wild conjecture about units and more consideration of the state of the art :-) (This is not aimed specifically at you Ethan, just a general observation of the discussion in this thread.) -- Steve

On Mon, Apr 4, 2022 at 11:55 AM Ken Kundert <python@shalmirane.com> wrote:

I think there is one more point worth making here. There is a suggestion that dimensional analysis can underpin a units system. Actually, the idea that all units can be broken down into a small set of fundamental units is very limiting and results in many vexing issues.

For example, consider currencies. There are currently hundreds of national currencies and thousands of cryptocurrencies. They all have the same basic fundamental unit of “value”, but value is only loosely defined. Furthermore, there is no fixed ratio between the currency and its value. It varies over time, over location, and from person to person.

Consider units of a particular commodity. The example of a ream of paper was recently mentioned. A ream is 500 sheets of paper. However two reams may not be comparable. They may refer to a different size of paper or a different quality of paper. So all prices for reams of paper would have the same fundamental units of “value per each”, but both “value” and “each” are not necessarily comparable. In effect, the fundamental unit system is not complete. You also need to include information about what you are measuring. For example, “each” could represent a single item of anything. The unit is not complete until you include a description of what that anything is, and in effect, there is an unlimited number of things it could be.

Now consider the issue of “unitless units”. In electrical circuit we often talk about gain, which it the ratio between the signal level at the output of a circuit relative to the signal level at the input. But you need to be specific about how you measure signal level. Typically, it would be a voltage, current, or power level. Consider a circuit where both the input and output are measured in volts. Then the gain would have units of "V/V", which is unitless in dimensional analysis. But units of "V/V" (voltage gain) is much different from units of "A/A" (current gain) or "W/W" (power gain), even though they have the same dimensions. Mixing them up results in errors and confusion. An additional complication is that sometimes logarithmic units are used. For example, decibels in voltage, or dBV, is 20*log(Vout/Vin). Again, a dimensionless quantity, but nonetheless "dBV" much different from "V/V".

The same issue occurs with the arguments to trigonometric functions like sin(), cos() and tan(). Generally, we assume the arguments are given in radians, which is a dimensionless number. But it could also be given in degrees, another dimensionless number. Radians and degrees are indistinguishable from the perspective on dimensional analysis, but mixing them up results in errors.

Just lending support to all of these comments. These are universal problems and far far from specific to electrical engineering. In civil we talk about strains and moments; strains are unitless, but they still carry a unit (e.g., in/in) and those units are important. We also talk about moments, which are the same dimensions as for energy (FORCE X LENGTH) but a wholly different thing with different unit expression (e.g., kip X ft). And there is also torque, which is the same units as a moment, but a different concept and you probably shouldn't be adding them together even though they are exactly the same units (someone might want to argue with me about that, I'm unsure). There is also the 2nd moment of area per length, which is the same dimensions as volume but we express it in different units than volume (in4/in), and there is section modulus per length, which is the same dimensions as area but different units (in3/in), and area per length, which is the same as length, but different units (in2/in or in2/ft). There is also the concept of loads: pressure loads (lbs/sq ft or psi), linear loads (lbs/ft, kips/in, etc), and these probably come out to have the same dimensions are other concepts in other disciplines that should not to be added to them. Since the concept of what a unit means is very very complex, what Chris A is saying about punting these responsibilities out to others is very powerful idea. I'm uncertain whether the idea of just calling functions as the consequence of applying unit tag to a number is the right solution (but I'm not against it). I wonder if having a totally separated namespace for the "unit slot" makes some kind of sense. Maybe you say something like: from pint.SI import as units meter as m, kilogram as kg from pint.US_Customary import as units feet as ft, pounds_force as lbf <<NOTE THE "*as units*" part above!!!>> ...and with the above "as units" imports you can say: m = "mosquito" lbf = "low battery freakout" kg = "kill goliath" ft = "foolish tolkien" x = 2m y = 5kg a = 4.0ft b = 4.1lbf ...etc. etc., and you have a unit namespace separate from the regular namespace. The m and lbf and ft and kg in these spaces never conflict. --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler

On Mon, Apr 04, 2022 at 11:05:54AM -0700, Ethan Furman wrote:

On 4/4/22 08:54, Ken Kundert wrote:

It seems to me that these "unitless' units actually have units, even if they *appear* to cancel each other out.

The term is *dimensionless* units. 1 dozen and 1 mole of objects both are dimensionless numbers, but if I asked for a dozen eggs and you gave me 1 mol (6.02 x 10^23) instead, I wouldn't have room to store them in the fridge. -- Steve

On Wed, Apr 06, 2022 at 12:28:49AM +1200, Greg Ewing wrote:

On 5/04/22 6:05 am, Ethan Furman wrote:

...

It seems to me that these "unitless' units actually have units, even if they *appear* to cancel each other out.

I think it's more that units alone don't capture everything that's important about the physical situation.

+1 This, a thousand times this! Neither dimensional analysis nor units capture all the semantics of calculations of real quantities. Both are powerful tools, but they do not capture everything interesting in the universe. For example, I'm going to try to draw some ASCII art of a rectangle with a diagonal line: +---+ | /| | / | |/ | +---+ We can capture the shape of the rectangle by giving the aspect ratio, let's say 1:2 using the convention width:height, which is another way of writing the fraction 1/2 = 0.5. Or we can give the gradient of the diagonal (rise over run), which is height/width, or 2. Or the angle made by the diagonal to the base, which would be arctan(2) in radians. Or the angle made by the diagonal to the vertical. In degrees. All these things describe the same rectangle, but they are numerically distinct, and tracking units "cm/cm" isn't going to tell you whether the number you have is an aspect ratio, gradient, angle or something else. -- Steve

On Sun, Apr 03, 2022 at 10:42:16PM -0400, Ricky Teachey wrote:

I was cheerleading this effort earlier and I still think it would be a massive contribution to needs of the engineering world to solve this problem at the language level. But boy howdy is it a tough but of a problem to crack.

More than 35 years of prior art says hello. My HP-28C calculator supported unit conversion in the mid 1980s, and a few years later HP were offering calculators that supported arithmetic on units. If you want to see some prior art, check out the chapters on Units here: https://web.archive.org/web/20150608024051/http://www.hp41.net/forum/fileshp... http://h10032.www1.hp.com/ctg/Manual/c00442266.pdf If you are on a Linux or Unix system, you can check out the "units" program: [steve@ando ~]$ units "3 ounces * 200 furlongs per fortnight" "kg m/s" * 0.0028288774 / 353.49711 Then there is also Frink: https://frinklang.org/ -- Steve

On 4/04/22 2:42 pm, Ricky Teachey wrote:

height = 5ft + 4.5in

Surely we ought to be able to add these values. But what should the resulting tag be?

One answer might be that the tag only tracks what kind of quantity it is -- length, mass, time, etc. Internally the number would be represented in a standard unit for each quantity. Whether to display it as feet or inches or a combination of both would then be a matter of formatting. A default could be chosen based on the magnitude of the number, and if you wanted something else you would have to specify it, just as with any other formatting decision.

Should we be able to write it like this?

height = 5ft 4.5in

With my "no new syntax" suggestion there would be no question here -- the only way to write it would be height = 5 * ft + 4.5 * in -- Greg

On Wed, Apr 06, 2022 at 12:30:47AM +0900, Stephen J. Turnbull wrote:

Greg Ewing writes:

...

With my "no new syntax" suggestion there would be no question here -- the only way to write it would be

height = 5 * ft + 4.5 * in

I'm very sympathetic to the "no new syntax" suggestion, but suppose I wanted to know how many cm there are in an in:

cm_per_in = 1 * in / 1 * cm

inch.definition() inch.convert(cm)

Of course that's a silly mistake, but the (sole, IMO) advantage of the original proposal is that you can't make that silly mistake.

Don't worry, I'm sure it will allow its own distinct silly mistakes :-) -- Steve

While units are certainly useful, I think this is FAR too large to add to Python syntax. A library like "units" is great, but it really needs to be a library, and not a small one. There are thousands of units in use in sciences, commerce, engineering, ordinary life, etc. In all of them, it is not uncommon for the same few letters to represent multiple things, depending on context. But as well as the sheer number, what is convertible to what, and in what context, is very nuanced. An electron volt is a unit of energy. Or of mass. Or of momentum. It's usual to convert among these meanings for these units. But bordering on nonsense to convert among kilowatt-hours and grams. It depends on the practical context of units. Even in Ethan's example, he uses kilogram as a unit of weight. It answers a question with the word weight in it (albeit 300 kg is extreme for a human weight, maybe for brick pallets). But kg IS NOT a unit of weight. It's a unit of mass. In the context of thing on the surface of the earth near the same elevation, we might convert between kg and lbs. But in other contexts it makes no sense. I'm older than 35 (Earth) years, but my age is also counted differently according to different calendars and cultural conventions. Of his examples, °F is the only one that is completely convertible to other temperature scales, but even there, it's rare to see a bread recipe in degrees Kelvin. Units like time intervals and currencies are EXCEEDINGLY complicated. The conversion rate between Dirham and USD fluctuates by microsecond, but can also have two simultaneous values on different exchanges. At the least, a unit of currency has built into it an absolute time, but also often a relative time to a specific refence time. ... So then we get to the point of saying "don't do any of that, just annotate the number with an arbitrary string/object." Which sure, is possible. Not even difficult. But we can also do it already without syntax by subclassing int, or float, or complex, or Decimal, or Fraction. Or we can do it just with name conventions too. Perhaps 'person_kg' is just a numeric variable reminding us of its unit. On Sun, Apr 3, 2022, 6:25 PM Chris Angelico <rosuav@gmail.com> wrote:

On Mon, 4 Apr 2022 at 07:45, Ethan Furman <ethan@stoneleaf.us> wrote:

...

Mechanically, are `lbs`, `km`, `hr`, etc., something that is imported, or are they tags attached to the numbers? If attached to the numbers, memory size would increase and performance might decrease -- but, how often do we have a number that is truly without a unit?

How old are you? 35 years How much do you weigh? 300 kg What temperature do you cook bread at? 350 F

Very frequently - it'd be called an index. (What sort of numbers should enumerate() return, for instance? Clearly that, whatever it is, is an index.) But if every int and float has a tag attached to it, it's not that big a deal to have either a default tag, or leave the field NULL or None, to define it to be a unitless value or index.

ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/7LTKML... Code of Conduct: http://python.org/psf/codeofconduct/

Native level support for units would be much more powerful and be much more worth the effort than libraries. Libraries already exist, and they are not sufficient.

On Mon, Apr 04, 2022 at 01:53:49PM +1000, Chris Angelico wrote:

And that's exactly why I think that the *concept* of units could be added to the language, with some syntax and low-level semantics, but the actual units themselves belong in libraries.

+1 on that. I'm not even sure about the need for syntax beyond what we already have. Yes, it would be nice to write: speed = 15 ft 3 in / 3 sec but is it really so painful to use existing syntax? speed = (15*ft + 3*in) / (3*sec) I don't think so. -- Steve

On Tue, 5 Apr 2022 at 14:25, Ricky Teachey <ricky@teachey.org> wrote:

units are at THE CORE of that need.

i think python should be the language we reach for. i have made python work for me as a civil engineer and been extremely successful with it for all the usual reasons: ease of learning and community backing that learning, the open source resources (libraries and applications), the momentum of the language, its ability to be a swiss army knife (need to transition to web? automate the boring thing? sure, easy).

I've been reading this discussion with gradually increasing levels of bemusement. I genuinely had no idea that handling units was so complex. But one thing I did note was that there are various libraries (at least one, I think I saw more than one mentioned) that do units handling. Why are those libraries insufficient? You said that "The motivation is much more than just being able to not have the * symbol", but no-one seems to have explained why a library isn't enough. After all, scientists manage with numpy being a library and not a core feature. Data scientists manage with tensorflow being a library. What's not sufficient for unit support to be a library? (And remember, the numeric users successfully got the @ operator added to the language by arguing from the basis of it being a sufficient enhancement to improve the experience of using numpy, after years of having requests for general "matrix operations" rejected - language changes are *more likely* based on a thriving community of library users, so starting with a library is a positive way of arguing for core changes). Paul

There are thousands of units in use in sciences, commerce, engineering, ordinary life, etc. In all of them, it is not uncommon for the same few letters to represent multiple things, depending on context.

Units in science and engineering are NOT AT ALL ambiguous. If they were, planes would be crashing every day. If we consider distinct sets of units, such as SI, there are guaranteed to not be any collisions in notation. Even English/Imperial and SI units do not conflict as far as I know. Commerce (finance?) is another story, so yes, there needs be groupings (i.e. - namespaces) of such things.

An electron volt is a unit of energy. Or of mass. Or of momentum. An electron volt is a unit of energy and only a unit of energy. Knowing a particle's energy (in certain situations) means that you also know other physical quantities about that object, and so in casual conversation (and the occasional poorly reviewed journal article) you find them used interchangeably. But that does not mean that an electron volt is a unit of mass. It just isn't. These units are set by standards. Standards do not leave any room for ambiguity. The only context needed is what standard applies. And there are LOTS of people who are familiar with these standards who could be called upon to lend a hand.

I'm older than 35 (Earth) years, but my age is also counted differently according to different calendars and cultural conventions. Of his examples, °F is the only one that is completely convertible to other temperature scales, but even there, it's rare to see a bread recipe in degrees Kelvin.

Dates and years are not standard units of time. The only SI unit of time is the "s" (second). The `datetime` object today is composed of unitless primitives and would continue to be so. The value returned by time.time() could remain unitless, or it could have a unit of seconds. Either one would make sense. So this is also not a problem.

Units like time intervals and currencies are EXCEEDINGLY complicated. The conversion rate between Dirham and USD fluctuates by microsecond, but can also have two simultaneous values on different exchanges. At the least, a unit of currency has built into it an absolute time, but also often a relative time to a specific refence time.

Would it help if we stopped saying "units" and instead referred to "standard units"?

On 4/4/22 07:25, David Mertz, Ph.D. wrote:

On Mon, Apr 4, 2022, 12:53 AM Brian McCall

> An electron volt is a unit of energy. Or of mass. Or of momentum. An electron volt is a unit of energy and only a unit of energy. Knowing a particle's energy (in certain situations) means that you also know other physical quantities about that object, and so in casual conversation (and the occasional poorly reviewed journal article) you find them used interchangeably.

This is just flatly wrong of usage in particle physics. Electron volts are precisely the default units used to describe the mass of subatomic particles.

I beg to disagree here, here---mass is measured in eV / c^2, and momentum in eV / c. (Although, as Brian says, we're all guilty of taking shortcuts in conversations.)

Would it help if we stopped saying "units" and instead referred to "standard units"?

Yes, limiting the idea to ""SI units" would cover far less. And thereby have far less motivation to change Python syntax rather than use a library.

_______________________________________________ Python-ideas mailing list --python-ideas@python.org To unsubscribe send an email topython-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived athttps://mail.python.org/archives/list/python-ideas@python.org/message/55MZRW... Code of Conduct:http://python.org/psf/codeofconduct/

-- =============================================================================== Luca Baldini Universita' di Pisa and Istituto Nazionale di Fisica Nucleare - Sezione di Pisa Largo Bruno Pontecorvo 3, I-56127, Pisa, ITALY. phone : +39 050 2214438 fax : +39 050 2214317 e-mail :luca.baldini@pi.infn.it icq : 396247302 (Garrone) web :http://www.df.unipi.it/~baldini mirror :http://www.pi.infn.it/~lbaldini ===============================================================================

On Mon, 4 Apr 2022 at 15:26, David Mertz, Ph.D. <david.mertz@gmail.com> wrote:

On Mon, Apr 4, 2022, 12:53 AM Brian McCall

...

...

An electron volt is a unit of energy. Or of mass. Or of momentum. An electron volt is a unit of energy and only a unit of energy. Knowing a particle's energy (in certain situations) means that you also know other physical quantities about that object, and so in casual conversation (and the occasional poorly reviewed journal article) you find them used interchangeably.

This is just flatly wrong of usage in particle physics. Electron volts are precisely the default units used to describe the mass of subatomic particles.

Not a particle physicist, so I don't know what the usage actually is, but wouldn't mass actually be eV/c²? If that's frequently written as simply "eV", then that's another example of common non-SI usage that really should be supportable, but only within its context. ChrisA

On Mon, 4 Apr 2022 at 16:41, Brian McCall <brian.patrick.mccall@gmail.com> wrote:

How something is used is not the same as how it is defined. I might use my car key to open my mail, but if I ask someone if they've seen my letter opener, they're probably not going to be able to help me find my car keys.

+1 QOTW!

Not sure what you mean by "cover far less". Even implementing just the 29 base and derived SI units would have a profound impact on the work done by engineers and scientists on a day to day basis. And the impact of such a change will only grow more in importance over time. As I mentioned in another reply, adding in the remaining SI units AND the Imperial / US Customary still only brings up a grand total of 160 units. There are other systems too, but they all use units that are defined elsewhere.

FWIW, I do not subscribe to the mindset of "Well, I had to do it this way, so why can't you kids learn to do it this way too?"

The 160 units would be more likely to have collisions though. Also, the base and derived SI units will be used with magnitude prefixes, which increases the effective number of collision chances. So I do still think they need to be kept separate - also because it allows units that Python never thought of. ChrisA

Back in my original post, I pointed out that engineers and scientists in their modern day workflows are expected to have basic programming language skills, and are expected to use those skills when pre-packaged software solutions leave gaps in their workflows, but they are explicitly told that they are not "paid to write code", leading to bad programming practices and wasted hours and (unpaid) overtime resolving issues that could have been avoided if there was an implementation of scientific and engineering units that was too easy use to be ignored. This is a problem that I have run into dozens of times, and at more than place. So yes, I am thinking about the real world. This is not an ivory tower fantasy. If a baker is writing python code, it's either a hobby or something that they plan to sell or are getting paid to do. Inventory systems have their own concept of units. But they also have dedicated teams of software engineers to handle whatever conversions and representations they need, and will continue to do so with unitless quantities. As I said originally, there is a real-world need for native or like-native support for standard scientific and engineering units is there, and it is growing. The only question is, should Python provide a solution? I can see that your answer is no, because it doesn't meet the needs of the bakers. I don't expect everyone to see updating or creating a new programming language to be the answer. But, no offense, the reasoning you have given for your opinion is not something that I can take seriously.

On Mon, Apr 4, 2022, 2:17 AM Brian McCall

For instance, I don't think there would be much uproar if "teaspoons" were left out of any kind of implementation.

Apparently someone other than you does the cooking in you household!

On Mon, Apr 04, 2022 at 06:16:49AM -0000, Brian McCall wrote:

So a comprehensive implementation of units would not require more than 160 units, and in reality, a "sufficient" implementation would need only 7.

The idea that a system which only supported the seven SI base quantities, and so couldn't even convert from imperial to metric, would be "sufficient" boggles my mind. Sufficient for what?

An exceptionally good implementation could probably be done with right around 100.

You must be easily pleased if you consider 100 units "exceptionally good". In 1986 the HP-28C calculator supported 120 units, plus user-defined units. If you don't at least reach the standard available in 1986, I'm not even sure if you reach "good", let alone exceptional. (And yes, the HP-28C included teaspoon and tablespoon, but not hogshead, Roman mile or furlong.) I would consider the Unix program "units", and Frink (which inherits its unit database from units), to be comprehensive. 160 units is about 7% of comprehensive. -- Steve

In the previous thread (Custom C++ literals), ChrisA raised some good questions, some of which I can actually answer :D

Part of the problem here is that Python has to be many many things. Which set of units is appropriate? For instance, in a lot of contexts, it's fine to simply attach K to the end of something to mean "a thousand", while still keeping it unitless; but in other contexts, 273K clearly is a unit of temperature. (Although I think the solution there is to hard-disallow prefixes without units, as otherwise there'd be all manner of collisions.) Is it valid to refer to fifteen Angstroms as 15A, or do you have to say 15Å, or 15e-10m and accept that it's now a float not an int? Similarly, what if you want to write a Python script that works in natural units - the Planck length, mass, time, and temperature?

I think if you look into CGPM standards (they're the grand pooh bahs who decide what SI units are) then you'd find that a lot of these potential collisions have already been encountered and resolved. Under SI, there is no ambiguity regarding K. K means Kelvin and only Kelvin, whereas k means 1000. Some units, like Å do pose challenges. We often substitute u instead of μ, which works fine since there don't seem to be any SI units that start with u. But we can't do likewise for Å, since A is already reserved for Amperes. The easy way out is to say Å is not SI, so it's out. But I would rather not see this feature limited to SI units only (although SI should be preferred). A somewhat gentler approach would be let Å be Å. Unicode letters are allowed in Python these days. I use theta, mu, lambda - the whole bunch of them, in my code all the time. If someone wants to use Å bad enough, let them use the unicode for it, otherwise use nm. Units like Planck's length are valid, and I don't see any reason to exclude them. The problem is that CGPM (nor anyone else, as far as I can tell) hasn't created an SI unit Planck length and other similar units that are lexicographically distinct from other units. And creating one would only be worth the trouble if all of the physicists who might use it could immediately recognize it. Not that I speak for them, but I'm guessing the folks who run SciPy or astropy could be of help in answering these sort of questions, rather than trying to get a Python steering committee to work with a possibly more bureaucratic organization like CGPM. Regarding precision, this is not something that so many scientists and engineers understand as well as computer scientists and engineers. I'd rather see units available for integers as well as floats. I think that as long as a unit is defined, it makes sense to allow integer quantities of them. If they are to built-in types, as I would prefer, then I suppose unfortunately one would not be able to define fractions of these units as new units. But again, most of this work is done with floats anyway, so if units were only available for floats, I would still see this as a big step forward. Related to these questions, there is the question of what to do about mixed systems? Should 2.54 in / 1 cm evaluate to 2.54 in/cm or should it evaluate to 1? I'd much rather it evaluate to 1, but if anyone else has a stronger opinion, I would not let a dispute over such a thing stand in the way of getting units. Regarding 1m / 1mm, though, I have a much stronger opinion. It should be 1000, without any units. There is yet another question related to the interpretation of K as 1000 vs Kelvin. As I said, SI is clear that K means Kelvin, but what about Python users that are not familiar with SI? What about those in the financial industry? To them, K means 1000, and might not even know what Kelvin is. Now, unless adding a suffix K to a number is supported later on, a financial person would have to go pretty far out of their way, or be looking at the wrong code to be confused by something referring to Kelvin. But it would indeed be a mistake to assume that everyone who uses Python wants and can live with SI units, or even that they would be using the same set of units! Which brings me to the next part of ChrisA's reply...

Purity and practicality are at odds here. Practicality says that you should be able to have "miles" as a unit, purity says that the only valid units are pure SI fundamentals and everything else is transformed into those. Leaving it to libraries would allow different Python programs to make different choices.

But I would very much like to see a measure of language support for "number with alphabetic tag", without giving it any semantic meaning whatsoever. Python currently has precisely one such tag, and one conflicting piece of syntax: "10j" means "complex(imag=10)", and "10e1" means "100.0". (They can of course be combined, 10e1j does indeed mean 100*sqrt(-1).) This is what could be expanded.

As I mentioned above, I am not a purist. I keep a set of Thorlabs thread adapters handy in my lab so that I can screw imperial cage plates onto metric posts. I think I diverge (or perhaps just don't understand) statement on "semantic meaning". To me, semantic meaning of the units seems pretty essential. Wherever possible, units should be simplified in a prescribed manner. 1W / 1s = 1J, 10km/1cm = 1000000. The meaning of these suffixes should be explicit, not implicit. Also, see above about precision of unit-aware data types. Floating point only would be fine, but I don't see why integers cannot be supported as well.

C++ does things differently, since it can actually compile things in, and declarations earlier in the file can redefine how later parts of the file get parsed. In Python, I think it'd make sense to syntactically accept *any* suffix, and then have a run-time translation table that can have anything registered; if you use a suffix that isn't registered, it's a run-time error. Something like this:

import sys # sys.register_numeric_suffix("j", lambda n: complex(imag=n)) sys.register_numeric_suffix("m", lambda n: unit(n, "meter")) sys.register_numeric_suffix("mol", lambda n: unit(n, "mole"))

(For backward compatibility, the "j" suffix probably still has to be handled at compilation time, which would mean you can't actually do that first one.)

Using it would look something like this:

def spread(): """Calculate the thickness of avocado when spread on a single slice of bread""" qty = 1.5mol area = 200mm * 200mm return qty / area

Unfortunately, these would no longer be "literals" in the same way that imaginary numbers are, but let's call them "unit displays". To evaluate a unit display, you take the literal (1.5) and the unit (stored as a string, "mol"), and do a lookup into the core table (CPython would probably have an opcode for this, rather than doing it with a method that could be overridden, but it would basically be "sys.lookup_unit(1.5, 'mol')" or something). Whatever it gives back is the object you use.

Does this seem like a plausible way to go about it?

As far as registering units, I think registering individual units is a bit much. Of course, several of these statements could be put inside a module or package to make things easier. But I also don't like that it means the syntax of the "literals" needs to be allowed during parsing, and left to the interpreter to figure out if the unit was registered. I do think it is reasonable to require programmers to "opt in" to using SI or other units, and possibly even specify which set or sets of units they intend to use. But if their constants are ill-formed, then that should still be caught during parsing and throw a SyntaxError. How that would be implemented behind the scenes, I don't know, but from a syntax point of view, I am envisioning something like a namespace statement with a new keyword (I propose `measure`). Here, I am referring to namespaces like `local` and `global`, not something like `argparse.Namespace`. Consider the following example as of today: ``` A = 1 global A A = 2 ``` This will generate a syntax error during parsing: SyntaxError: name 'A' is assigned to before global declaration Similarly, what I envision is something like this: ``` length = 12m ``` SyntaxError: invalid syntax ``` measure SI length = 12m width = 10mm area = length * width print(area) ``` ... with no SyntaxErrors and a result of "0.12 m2" After the "measure SI" statement, all literals that are formed with SI units are considered valid syntax and are evaluated accordingly. Prior to "measure SI", only the unitless primitives are allowed. Clearly this works differently than does the `global` or `local` statement, which are modifying a namespace. Also, the choice of keyword matters, because making "measure" a keyword would probably break a lot of existing code (3to4.py!!!). But it is dead simple, and it does behave in a way that is actually quite similar to modifying the existing namespace. This ended up being a much longer reply than I anticipated, but I hope it helps.

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.

On Tue, 5 Apr 2022 at 04:19, Ethan Furman <ethan@stoneleaf.us> wrote:

On 4/3/22 22:39, Chris Angelico wrote:

...

On Mon, 4 Apr 2022 at 14:22, Brian McCall wrote:

...

...

Related to these questions, there is the question of what to do about mixed systems? Should 2.54 in / 1 cm evaluate to 2.54 in/cm or should it evaluate to 1?

I would say that 2.54in/1cm should be equal to 1. Units should completely cancel out.

It seems like the point of this exercise is to *not* have units cancel out -- at least, not unnecessarily.

2.54in / 1 cm should be 2.54in/cm, otherwise multiplying by 5 kelvin will be one of those hard-to-find bugs.

Hmm, fair point, I guess. It gets tricky, though. For an example, let's look at fuel efficiency. Outside of the US, vehicle fuel economy is measured in liters per hundred kilometers. What unit category should this be considered to be? 5 L/100km in SI units is 5e-3 m³ / 1e5m. That's 5e-8 m². Or if you prefer, 50mm². Fuel economy is a unit of area. https://what-if.xkcd.com/11/ This DOES, as Munroe points out, have a geometric interpretation. I think it's reasonable to say that fuel economy cancels down to a unit of area, and it's *also* reasonable to say that it doesn't, and that it simply remains as volume-per-distance. Some unit cancellations really do result in pure scalars. The ratio of a circle's circumference to its diameter isn't a unit of m/m any more than the ratio of a circle's area to that of a circumscribed square is a unit of m²/m². They're both just numbers. On the other hand, a radian is a very real unit of distance/distance (based on its definition of arc length), and it's a unit of angle. I suspect that the rules of cancellation would be best handed off to libraries, and there will be different choices for different applications. Maybe at some time in the future, there'll be a proposal to lock it down and define it more by the language. It wouldn't be the first time - type hints are now the only officially supported form of annotations, but the precise meanings of those hints is still partly up to the library.

Of course, it's actually 2.54cm/in.

(I actually didn't even spot that part) ChrisA

On Tue, 5 Apr 2022 at 11:44, Steven D'Aprano <steve@pearwood.info> wrote:

On Tue, Apr 05, 2022 at 04:36:24AM +1000, Chris Angelico wrote:

...

Some unit cancellations really do result in pure scalars. The ratio of a circle's circumference to its diameter isn't a unit of m/m any more than the ratio of a circle's area to that of a circumscribed square is a unit of m²/m². They're both just numbers.

Of course it is a ratio. You said it yourself: it is a ratio of circumference to diameter.

That ratio is only numerically equal to π if the units you measure the cicumference and diameter are the same. Otherwise it has units "inches/cm" (or whatever units you used) and a completely different numerical value.

...

On the other hand, a radian is a very real unit of distance/distance (based on its definition of arc length), and it's a unit of angle.

The SI system defines both radians and steradians as dimensionless derived units, previously known as "supplementary units".

You're missing the point: these are ALL dimensionless values, yet they are incompatible. Regardless of the units used to measure the circumference and diameter, they will *by definition* cancel out and leave you with pi (case in point: using a pie as the unit https://www.youtube.com/watch?v=ZNiRzZ66YN0 ). But a radian and a steradian are not the same type of thing. Nor is an index of refraction.They're all dimensionless. They're NOT all fungible. The unit type "inches/cm" is meaningless, but the unit type "length/length" is very meaningful. And that's where the problem comes in. Please, stop being all caught up on one small error that I propagated, and look at the actual point? You're really good at this sort of thing. ChrisA

On Mon, Apr 04, 2022 at 03:39:26PM +1000, Chris Angelico wrote:

I would say that 2.54in/1cm should be equal to 1.

2.54 inches is not 1 cm. This is how you get a billion dollar spacecraft crashing into Mars instead of landing softly :-) -- Steve

On Mon, Apr 04, 2022 at 04:22:25AM -0000, Brian McCall wrote: [Chris]

...

Part of the problem here is that Python has to be many many things. Which set of units is appropriate? For instance, in a lot of contexts, it's fine to simply attach K to the end of something to mean "a thousand", while still keeping it unitless; but in other contexts, 273K clearly is a unit of temperature.

Python is a programming language. I think we can require a certain minimum level of strictness, and reject ambiguity. Please read the Frink FAQ, especially the part about DWIM: https://frinklang.org/faq.html K means Kelvin, end of story. We don't need to support informal use or slang out of the box. But if units are scoped, like variables are, then people who really, really want K to mean 8192 bits can shadow the unit database with their own.

Should 2.54 in / 1 cm evaluate to 2.54 in/cm or should it evaluate to 1? I'd much rather it evaluate to 1

There are only two reasonable ways to parse that, depending on precedence of units and operators: * (2.54 inches) / (1 cm) = 6.4516 (dimensionless) * (2.54 inches / 1) * cm = 6.4516 cm**2 (or 1 square inch) If there is a third way, I can't think of it. In any case, I don't see how you can get 1. Maybe you mean 1 inch per 2.54 cm? This is why we need unit management :-) -- Steve

On 4/04/22 10:47 am, dn wrote:

You wouldn't believe it - have interrupted typing here to receive a package. However, the clothing delivered is NOT the size ordered...

Let me guess, you ordered it in cm but they delivered it in inches?-) -- Greg

Now do it for NumPy arrays

On 5/04/22 5:17 am, Steven D'Aprano wrote:

However, I suspect that having an array of unit objects rather than low-level machine ints or floats will reduce the performance of numpy a lot.

If numpy were to incorporate units, I would expect there to be just one unit tag for the whole array. -- Greg

On 4/6/22 08:50, Brian McCall wrote:

Alright, now let's look at an example. Again, it's not my best, let's go with it. This is just a calculation of the expected number of photons to reach a pixel through a camera of a given f-number (F). I mentioned this has bitten me before. All that means is that based on a set of simulations, we though something was possible, spent a few weeks building a prototype, got results that made no sense, and then realized that there was a unit error in the original feasibility analysis. That one was on me, and since I am a capable programmer, I ought to have been using a units package.

Thank you for all the examples, that should help a lot. Out of curiosity, those are the corrected versions of the code? Where was the mistake in the original? -- ~Ethan~

Oops, my examples have some other problems:

# λ = 550e-9nm

should be

# λ = 550nm

and

# λ = 550e-9 [nm]

should be

# λ = 550 [nm]

On Wed, 6 Apr 2022 at 16:51, Brian McCall <brian.patrick.mccall@gmail.com> wrote:

Before I get to this example, though, there is more to arguments for the "need" than just counter-examples. I keep using quotes because nothing is really a need for anything.

Yes, it's not about "need" in an absolute sense, but more about whether the gains justify the costs. In this case, the costs are non-trivial, because there's very little prior art (at least that I know of) in other programming languages in this area. So there's a learning curve, making Python a bit less approachable for the average programmer, which offsets the benefits to people who gain from this sort of functionality. And that's on top of the usual costs of any syntax change/new language feature.

Alright, now let's look at an example. Again, it's not my best, let's go with it.

Thanks for this, it helps a lot to have something concrete.

Symbol definitions: h - Planck's constant c - speed of light Ee - irradiance R - reflectance Q - quantum efficiency F - f-number λ - wavelength a - width of a pixel t - exposure time ȳ - output of luminosity function integral

From here, if the triple tick marks do not render this example in monospace for you, then I recommend copy/pasting into something that does.

``` echo no units

python -c " h = 6.62607015e-34 c = 299792458 Ee = 200 R = 0.25 Q = 0.63 F = 2.4 λ = 550e-9 a = 3.45e-6 t = 30e-3 ȳ = 683 n = (Ee * R * Q * λ * t * a**2) / (2 * h * c * ȳ * F**2)

Someone's already asked, so I know that the issue was with the value given to one of the constants, rather than with the formula. And I know all of this is intended to be read by specialists, not by the likes of me, but I wonder whether some comments might have helped here, as well? t = 30e-3 # exposure time (seconds) There's a subtle difference between "scripting" and "programming", and as a programmer, I'd almost certainly add comments like this. But if I was writing a script, I wouldn't. However, I'd generally not trust the output of a script as much as I would that of a program. (Jupyter notebooks fall somewhere in between, for what it's worth...)

# n = (200 * 0.25 * 0.63 * 550e-9 * 30e-3 * (3.45e-6)**2) / (2 * h*c * 683 * 2.4**2) print(n) "

# Pros - compact, the code representing the equation is easily verifiable, and the magnitudes are also easily verifiable

Given that the error was in the magnitude of one of the values, "magnitudes are easily verifiable" doesn't really seem that correct...

# Cons - no units

Agreed, this is just using Python as a glorified calculator. I understand that this is just an example, but I *am* curious, is the bulk of what you do simply calculations like this, or do your more complicated examples tend to be more like actual programs?

echo What literals would look like python -c " # h = 6.62607015e-34m2kg / 1s # c = 299792458m / 1s # Ee = 200lx # R = 0.25 # Q = 0.63 # F = 2.4 # λ = 550e-9nm # a = 0.00345mm # t = 30ms # ȳ = 683lm / 1W # n = (Ee * R * Q * λ * t * a**2) / (2 * h * c * ȳ * F**2) # n = (200lx * 0.25 * 0.63 * 500nm * 30ms * (3450nm)**2) / (2 * h*c * 683lm/1W * 2.4**2) " # Pros - Still compact. Dead simple. Planck's constant looks a little weird, but this is usually imported from a library anyway # Cons - requires a syntax change; inline computations like the last line are not IMO quite as readable as the next example

What would the output of "print(n)" be here? Presumably you'd be expecting some sort of calculation on the units, so you didn't just get something like 3958.0636423739215lxnm3msWs2/m2kglm Or is that sufficient for you (I note that it's the same as units provides, below)? Excuse me if I got the scale of the constant wrong, you changed the units between the no-units example and this one (t, for example was seconds and is now ms).

echo 'What bracket syntax might look like' python -c " # h = 6.62607015e-34 [m**2*kg/s] # c = 299792458 [m/s] # Ee = 200 [lx] # R = 0.25 # Q = 0.63 # F = 2.4 # λ = 550e-9 [nm] # a = 0.00345 [mm] # t = 30 [ms] # ȳ = 683 [lm/W] # n = (Ee * R * Q * λ * t * a**2) / (2 * h * c * ȳ * F**2) # n = (200[lx] * 0.25 * 0.63 * 500[nm] * 30[ms] * (0.00345[mm])**2) / (2 * h*c * 683[lm/W] * 2.4**2) "

# Pros - Still compact, dead simple, and IMO the best way to look at this code # Cons - requires a syntax change and a new kind of namespace in addition to global, nonlocal, and enclosure

This is basically just a different bikeshed colour for the previous example, I think. Is that right?

echo units python -c " from units import unit h = unit('m**2*kg/s') (6.62607015e-34) c = unit('m/s') (299792458) Ee = unit('lx') (200) R = 0.25 Q = 0.63 F = 2.4 λ = unit('nm') (550) a = unit('mm') (0.00345) t = unit('ms') (30) ȳ = unit('lm/W') (683) n = (Ee * R * Q * λ * t * a**2) / (2 * h * c * ȳ * F**2) print(n) n = unit('lx')(200) * 0.25 * 0.63 * unit('nm')(550) * unit('mm')(0.00345)**2 * unit('ms')(30) / (2 * 2.4**2 * h*c) / unit('lm/W')(683) print(n) "

This seems pretty readable to me, but I concede I'm a non-expert in this field. However, it's very hard to judge this without seeing the output. So I installed units and ran it, and I get 3958063642373921964032.00 lx * mm * mm * nm * ms / m**2*kg/s * m/s * lm/W Hmm. I'll take your word for it that this (a) is readable and useful to you, and (b) would have helped you spot the error you made.

# Pros - Has units, and no syntax change required

A significant pro, in my view. Not least because it means you can use it *right now*.

# Cons - less compact

I guess so, but compactness isn't typically regarded as a significant selling point for a proposal.

# Cons - How do you get the final answer? You need to know that units became astropy.units and see below

Please can you explain this to me? I don't know what you mean by "get the final answer", nor do I know how astropy.units is relevant. Units seems to be a perfectly acceptable library without astropy, is that not the case?

# Cons - Not dead simple. Multiple adjacent ()() is going to be unpopular with the crowd that uses Python as if it were Fortran/Matlab

It seems dead simple to me, and as for the adjacent parentheses, presumably you can name the units you need, like: ms = unit('ms') t = ms(30) It's not as close to natural language as "30 ms", but again, that's a fairly minor disadvantage in these types of discussion (and opens up a lot of debate about subjective issues like what "looks natural").

echo astropy.units python -c " import astropy.units as units h = 6.62607015e-34 * units.m**2*units.kg/units.s c = 299792458 * units.m / units.s Ee = 200 * units.lx R = 0.25 Q = 0.63 F = 2.4 λ = 550 * units.nm a = 0.00345 * units.mm t = 30 * units.ms ȳ = 683 * units.lm / units.W n = (Ee * R * Q * λ * t * a**2) / (2 * h * c * ȳ * F**2) print(n) n = (200*units.lx * 0.25 * 0.63 * 550*units.nm * 30*units.ms * (0.00345*units.mm)**2) / (2 * h*c * 683*units.lm/units.W * 2.4**2) print(n) print(n.decompose()) "

# Pros - Has units, and no syntax change required # Cons - less compact, everything is an instance of numpy.ndarray which will break some existing code # Cons - .decompose() is required to convert final result # Cons - dot-notation is better than ()(), but again will encounter resistance from those who use Python as if it were Fortran/Matlab

As has been mentioned, if you don't like "units." then "from astropy import units as U" and use "U.ms" of "from astropy.units import ms" and use ms directly. The fact that things are ndarrays is presumably because astropy is intended for use with numpy. I would not expect a library for general use to have such a constraint. I don't know why .decompose() is needed, but again that's an implementation detail of astropy.

echo astropy.units again, but importing everything into globals python -c " from astropy.units import * h = 6.62607015e-34 * m**2*kg/s c = 299792458 * m/s Ee = 200 * lx R = 0.25 Q = 0.63 F = 2.4 λ = 550 * nm a = 0.00345 * mm t = 30 * ms ȳ = 683 * lm/W n = (Ee * R * Q * λ * t * a**2) / (2 * h * c * ȳ * F**2) print(n) n = (200*lx * 0.25 * 0.63 * 550*nm * 30*ms * (3450*mm)**2) / (2 * h*c * 683*lm/W * 2.4**2) print(n) print(n.decompose()) "

# Pros - Compact, has units, and no syntax change required # Cons - Everything is an instance of numpy.ndarray which will break some existing code

Already noted above

# Cons - Can't use "m" as a counter (and other namespace collisions)

Don't use "import *" then, just import the names you need.

# Cons - .decompose() is required to convert final result

Already noted above.

# Cons - dot-notation is better than ()(), but again will encounter resistance from those who use Python as if it were Fortran/Matlab

Already noted above.

echo Quantiphy [...] # Ugh

No further comment :-) These examples were very useful. Thanks for providing them. I'm not trying to shoot them down by doing a point-by-point response, but I wanted to explain some of my thoughts. Overall, my feeling is that the existing library solutions might not be ideal, but they do broadly address the requirement, as I interpret it from your explanations. Yes, the notation may be suboptimal for an expert, but there's always going to be *some* level of compromise needed, and having to write "35 * mm" rather than "35 mm" doesn't seem impossible. On the other hand, it seems clear to me that the various libraries all have their problem points at the moment. Maybe that suggests that there's room for a unified library that takes the best ideas from all of the existing ones, and pulls them together into something that subject experts like yourself *would* be happy with (within the constraints of the existing language). And if new syntax is a clear win even with such a library, then designing a language feature that enables better syntax for that library would still be possible (and there would be a clear use case for it, making the arguments easier to make). I should say, though, that I doubt I'll ever use such a new syntax, or even the existing libraries, for anything other than experimentation. So treat my comments with that in mind. Paul

On Wed, Apr 6, 2022 at 7:05 PM Mike Miller <python-ideas@mgmiller.net> wrote:

On 2022-04-06 12:36, Paul Moore wrote:

...

And if new syntax is a clear win even with such a library, then designing a language feature that enables better syntax for that library would still be possible (and there would be a clear use case for it, making the arguments easier to make).

If folks are really hung up on the syntax limits, there is shortcut to prototype new syntax using the codecs module to edit code on the fly. It's a cheat, but probably less work than writing a transpiler/dsl.

Don't remember who invented the technique, but the last project I tried was to support f-strings under Python of pre-3.6 vintage, called future-fstrings:

https://github.com/asottile-archive/future-fstrings

There is also my ideas module https://aroberge.github.io/ideas/docs/html/ which I created to facilitate this type of exploration. In fact, I made a note just two days ago about doing this myself https://github.com/aroberge/ideas/issues/16 André

Should be enough there to show how it's done.

Why not try this technique, combine with one of the libraries, and start writing some code? If it works well enough and enough folks are interested, the proposal would all the evidence it needs, imho.

-Mike

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/MKZW5U... Code of Conduct: http://python.org/psf/codeofconduct/

Agreed, this is just using Python as a glorified calculator. I understand that this is just an example, but I *am* curious, is the bulk of what you do simply calculations like this, or do your more complicated examples tend to be more like actual programs?

I have never shipped code that would depend on these features. Code like this, including this exact formula, might sit in a script and be used to calculate normalization factors and feed into a noise model. That script might look at one complete concept that I want to test out in theoretical sense. In other cases, I'll make one or more of those quantities out to be variables that I pass in via command line or config file. This allows me to explore a system design space. I used to ship code when I worked in telecom ~15 years ago, and that was mostly C++. Units were not a concern. I shipped C++ and Python code 2-5 years ago at another company (startup) which did not require units, but I also did my feasibility assessments with stuff like this that did depend on units.

Given that the error was in the magnitude of one of the values, "magnitudes are easily verifiable" doesn't really seem that correct...

... ah, I mean the mantissa, not the magnitude

Please can you explain this to me? I don't know what you mean by "get the final answer", nor do I know how astropy.units is relevant. Units seems to be a perfectly acceptable library without astropy, is that not the case?

Am I mistaken, or is the units module no longer maintained? I could not find any documentation for it. Which is also a con. I honestly thought that "units" took on a new life as "astropy.units".

As has been mentioned, if you don't like "units." then "from astropy import units as U" and use "U.ms" of "from astropy.units import ms" and use ms directly.

As an fyi, lots of single-letter variables are commonly used to match variables in physics and engineering equations. U and u are of particular importance in my field.

Don't use "import *" then, just import the names you need.

Still rules out a lot of commonly used variables. ¯\_(ツ)_/¯

Maybe that suggests that there's room for a unified library that takes the best ideas from all of the existing ones, and pulls them together into something that subject experts like yourself *would* be happy with (within the constraints of the existing language)

Just to point out, I don't make this suggestion just for my benefit. I can handle all of the syntax limitations that I pointed out. I am in a somewhat unique position of having a BS in computer engineering, but I have worked for 10+ years now in the optics industry, along with physicists, electrical engineers, and mechanical engineers. I was taught in school all about OOP, data structures, all that stuff. But most of the people I know today who write code do not have any formal training in this area. There are varying ranges of comfort with things like logical indexing, dot-notation (which you and I take for granted) and functions as objects that can be returned by other functions. I have seen code that looks like spaghetti served in a bowl that was shattered and put back together with duct tape. And some of it is related to units. If I make suggestions like what you have made, the response I tend to get is "my code works". Which would be fine with me if I never had to use their code. Others who feel strongly about units, or dual threat CS/ECE types who have to work with self-taught programmers with physics or chemistry backgrounds may have other stories.

On Thu, 7 Apr 2022 at 01:18, Brian McCall <brian.patrick.mccall@gmail.com> wrote:

...

Please can you explain this to me? I don't know what you mean by "get the final answer", nor do I know how astropy.units is relevant. Units seems to be a perfectly acceptable library without astropy, is that not the case?

Am I mistaken, or is the units module no longer maintained? I could not find any documentation for it. Which is also a con. I honestly thought that "units" took on a new life as "astropy.units".

I honestly have no idea. I simply did `pip install units` and it worked. If the units module is no longer maintained, then who would write (and maintain) a module that worked with any core python syntax to allow units to be added to quantities? (Note that any core feature would simply allow something like 3_ft to be written to mean the number 3, with some object associated with the name "ft" attached to it - it would be up to a 3rd party module to actually implement the units calculations). It doesn't look like the astropy people want to maintain a generalised units library if they are solely working with numpy arrays. Also, you didn't explain what you meant by "get the final answer" - I'm still not clear with what you want beyond doing the calculation as you showed in your code.

...

As has been mentioned, if you don't like "units." then "from astropy import units as U" and use "U.ms" of "from astropy.units import ms" and use ms directly.

As an fyi, lots of single-letter variables are commonly used to match variables in physics and engineering equations. U and u are of particular importance in my field.

...

Don't use "import *" then, just import the names you need.

Still rules out a lot of commonly used variables. ¯\_(ツ)_/¯

If your community typically uses short and frequently clashing names, relying on context and intuition to distinguish them, there's nothing a library or language feature can do to help with that... As I said, there have to be some compromises made. Paul

Previously you were adamant that it is important that the units be propagated into the final result. In my experience this rarely works out as one expects because the units come out in an overly complicated, confusing form or unexpected form. For example, you gave the units for Planck's constant as m²kg/s which to me was confusing and unexpected. It took me a while to confirm that was equivalent to J-s, which is the more traditional way of specifying its units. To show the value of what you are proposing, you should give the units of the final result. The fact that they are missing significantly weakens your example. Given your previous comments about the importance of propagating the units, it is a little weird that in your one example you don't bother to show it. It is unclear what these examples are meant to show. Is the point to compute the final units of n? If so, why did you not show them. If not, why were the units specified at all? Are they primarily there for documentation purposes? If so, can't you just put them in comments. If the units need to be in the code because they are employed somehow, you should show that. I am still not understanding your justification for why you want to add units to Python. This application seems like a one-time hand calculation rather than a programming problem. Perhaps a better approach would simply be to build a units aware scientific calculator application. That was you could design the best way to include units without any constrains from the Python calculator. -Ken

Brian McCall writes:

Stephen J Turnbull and Paul Moore have asked why the "need" for something other than a library (or perhaps a better library). There are a number of examples that show simple unit calculations and it's easy to argue based on those that nothing further is needed.

Nobody is arguing that, though. We ask *because* we believe you perceive need (and we don't put it in quotes, for exactly the reason you give -- we do not define "need" as "if I don't get it I will literally die"). You don't need to prove your need to Python core. You need to show two things. (1) The particular solution proposed solves problems that already available approaches don't (including "too inconvenient to consistently use in practice" which might apply to the library approach vs the user-defined literal approach). (2) There are enough people with this need to outweigh the slight costs to all Python users of maintaining the facility, documenting it, and learning it, and possibly preventing a more valuable use of the same syntax.

In regulated environments, risk analysis and mitigation is very much affected by whether a feature has native support

That you say this after citing Paul of all people gave me a chuckle, as he's probably the most prominent advocate of a comprehensive standard library on these lists. If anybody will be sympathic to your needs on these grounds, he will. (I don't expect you to know that, but it might be useful to know you have a potential ally.) It's important to distinguish between several levels of "native support" here. 0. Adding units to all numeric objects. I don't think level 0 is a very good idea. I think it was Mac Lane who pointed out that the solution to a problem expressed in mathematics starts by giving a formal statement of the problem, manipulates the form according to syntactic rules, and finally interprets the final form as a semantic solution to the problem. Similarly, as long as the expected units of the result, and the units output by a Python program are the same, the numbers don't need to have units. I suspect that from the point of view of astropy, attaching units to ndarray rather than atomic numeric types is optimal for this reason, not a workaround. 1. Syntax, aka language support (the original suggestion of user-defined literals fits here because either the way numbers are parsed or the way '_' is parsed would have to change). It's very difficult to get *any* syntax change in. In particular, changing '_' from an identifier component to an operator for combining numeric literals would invalidate *tons* of code (including internationalization code that is the 0.454kg nearest my heart). I can't imagine that being possible. There was a fair amount of pushback to using it as the non-capturing marker in the match statement. Changing its interpretation only in a numeric literal is probably possible, since as far as I know it's currently an error to follow a sequence of digits with _ without interposing an operator or whitespace. NOTE: The big problem I see with this is that I don't see any practical way to use syntax for non-numeric types like ndarray. The problem is that in, say, economics we use a lot of m x 2 arrays where the two columns have different units (ie, a quantity unit and a $/quantity unit). The sensible way to express this isn't some kind of appended syntax as with numbers, but rather a sequence of units corresponding to the sequence of columns. If I'm right about that, the only time the literal would be used syntax is when using Python interactively as a calculator. Any time you read from a string or file, you have to interpose a parsing step anyway, so it makes sense to handle the construction of quantities there. 2. Built-in, that is pre-loaded in the interpreter. These are implemented as library functionality in the builtins module. I would definitely be against level 2. It would pollute the builtin namespace to the great detriment of all non-numeric applications. 3. Modules in the standard library. Always available, but must be explicitly imported to be used. I think adding a module that provides units for the stdlib numeric types is a very interesting idea. I doubt I'd ever use it, and I'm not sure that the requirements can be well-enough specified at the moment to go to +1 on it. (As the Zen says, "Although never is often better than *right* now.) For me, level 4 (available on PyPI) is good enough. I can think of cases where it would be useful for class demos to be able to interrogate a computation for its use of units, but that's about it. So I depend on descriptions of proponents' use cases to sort out the question of level 1 vs. level 3.

...

The Mars Climate Orbiter [...] navigation error arose because a NASA subcontractor (Lockheed Martin) used Imperial units (pound-seconds) instead of the metric system.

These examples don't need to be repeated over and over again, though. What is needed is to show that a particular proposal is especially effective in preventing them compared to others. This is what I haven't seen.

One last pontification before I get to my example relating to units. We already have examples of features that have both a native implementation and library extensions. int and float are primitives in Python. They are more than enough for most users, but limiting for quite a few other users. So modules like fractions and decimal provide extended support, and libraries like numpy provide even more data types for task-specific needs.

?? That analogy looks like an argument for users who need units to get facilities suited to their needs in libraries like numpy and units.

That one was on me, and since I am a capable programmer, I ought to have been using a units package.

This is the big question, to me: will people be so much more likely to use units with syntactic support than they are with something like the units package plus a simple facility for getting the great majority of units they use with one import or function call?

echo What literals would look like python -c " # h = 6.62607015e-34m2kg / 1s

That's pretty unreadable IMO. And how do you distinguish k(m2) from (km)2? Is latter always going to be the natural reading?

echo 'What bracket syntax might look like' python -c " # n = (200[lx] * 0.25 * 0.63 * 500[nm] * 30[ms] * (0.00345[mm])**2) / (2 * h*c * 683[lm/W] * 2.4**2) "

This is quite readable for me. The unit "sticks to" the number nicely. I guess the parentheses in "(0.00345[mm])**2" are unnecessary? This also has the k(m2) vs (km)2 issue, if it's real.

echo units python -c " from units import unit h = unit('m**2*kg/s') (6.62607015e-34) [...] n = unit('lx')(200) * 0.25 * 0.63 * unit('nm')(550) * unit('mm')(0.00345)**2 * unit('ms')(30) / (2 * 2.4**2 * h*c) / unit('lm/W')(683) print(n) "

# Pros - Has units, and no syntax change required # Cons - How do you get the final answer?

I don't understand the question:

...

...

unit('m')(1) * unit('kg')(1) Quantity(1, ComposedUnit([LeafUnit('m', False), LeafUnit('kg', False)], [], 1)) str(unit('m')(1) * unit('kg')(1)) '1.00 m * kg'

You need to know that units became astropy.units and see below

This isn't a con, because you're proposing to change the Python distribution. Some form of some library would be added to the stdlib. If you can't do that, there's no way you're going to get syntax to support not doing it. :-)

# Cons - less compact # Cons - Not dead simple. Multiple adjacent ()() is going to be # unpopular with the crowd that uses Python as if it were # Fortran/Matlab

Both of these can be addressed with a prologue mps = unit('m/s') lx = unit('lx') and so on. I would expect that various fields would develop their own abbreviations that would be commonly used. You missed one "con", here. This won't handle SI prefixes in a natural way. I guess the unit() constructor can do it, but it seems pretty nasty from the point of view of a Pythonista to have to define all of m, km, mm, g, kg, and mg when you could get away with m and g, and k and m, and obviously it gets a lot worse as we go to the full suites of prefixes and units.

echo astropy.units again, but importing everything into globals python -c " from astropy.units import * [...] # Cons - Can't use "m" as a counter (and other namespace collisions)

You could limit the name collisions by having field-specific submodules. Losing 'm' would be painful, though. I guess you could use "meter" instead, and ask those who want the abbreviated unit to assign m = meter. But most of the comments above aren't particularly important. The key question remains: How often would the syntax prevent an error that adding an appropriate units library to the stdlib would not? Among other things, in a later post you wrote

Oops, my examples have some other problems:

...

# λ = 550e-9nm

should be

...

# λ = 550nm

I can easily see myself making this mistake, hearing "lambda equals 550 nanometers", writing "λ = 550e-9", thinking "I really should add the explicit units, and appending "nm" because that's the unit I heard. Explicit units won't fix that, nor will syntax for explicit units. So you need to make sure that when people say "I make units mistakes a lot" they mean "I think 1000kg as I enter '1000' into a text box that expects lb", not "my SI prefixes frequently duplicate my engineering notation exponents".

On Fri, 8 Apr 2022 at 00:48, Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:

1. Syntax, aka language support (the original suggestion of user-defined literals fits here because either the way numbers are parsed or the way '_' is parsed would have to change).

It's very difficult to get *any* syntax change in. In particular, changing '_' from an identifier component to an operator for combining numeric literals would invalidate *tons* of code (including internationalization code that is the 0.454kg nearest my heart). I can't imagine that being possible.

...

...

123_456 123456 123_456_ File "<stdin>", line 1 123_456_ ^ SyntaxError: invalid decimal literal

Trailing underscore is currently invalid, so that would be fine. ChrisA

On Thu, Apr 7, 2022 at 10:51 AM Stephen J. Turnbull < stephenjturnbull@gmail.com> wrote:

NOTE: The big problem I see with this is that I don't see any practical way to use syntax for non-numeric types like ndarray. The problem is that in, say, economics we use a lot of m x 2 arrays where the two columns have different units (ie, a quantity unit and a $/quantity unit). The sensible way to express this isn't some kind of appended syntax as with numbers, but rather a sequence of units corresponding to the sequence of columns.

Here's a few minutes of work by me:

...

...

df = pd.DataFrame([['Apples', 11, 2], ['Pears', 12, 3]], ... columns=[Units("Item", "Kind-of-Fruit"), Units("Per-Bushel", "USD/bushel"), Units("Number")]) ... ... df Item Per-Bushel Number 0 Apples 11 2 1 Pears 12 3 df.columns[1].units 'USD/bushel'

I did this by defining:

...

...

class Units(str): ... def __new__(self, s, units="Dimensionless"): ... return str.__new__(self, s) ... def __init__(self, s, units="Dimensionless"): ... float.__init__(s) ... self.units = units

If this were actually needed, I'm sure better interfaces could be created. But this very simple thing is a possible way to retain units per-column. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.

What does it *really* matter which of these you write?

that's just arguing over the colour of the bikeshed.

you have shown nothing to justify why unit support must be built into the language itself.

I did what I could, but I'm not going to try and justify any more. At the end of the day, units are a core part of science and engineering. Scientists and engineers are freaking passionate about units. More and more of them are also being expected to write code to do their jobs. To me that says it's going to happen at some point. It might be 10-20 years, and it might not be Python. But there will be a programming language, likely built on what Python is today, with native support for SI base units and derivatives. The unit torque vs unit unit energy problem will also be resolved. With support at the native level, the language syntax, parsers, standard library and third party libraries will have an enhanced ability to support any locale's version of units, as well as the varieties of dimensionless quantities that have been mentioned - like A/A and V/V. Such is my prediction.

On Fri, Apr 8, 2022, 2:40 AM Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:

Brian McCall writes:

...

...

...

...

Steven d'Aprano writes:

...

...

you have shown nothing to justify why unit support must be built into the language itself.

I did what I could, but I'm not going to try and justify any more.

That makes me sad, because everybody in the thread acknowledges that improving the Python distribution's support for units is a good idea, but nobody is as enthusiastic about getting it done as you.

Chris Barker's comments about multiple attractive library implementations are well-taken, I think, but I also think that with more focus on getting a satisfactory module into the stdlib, it would be quite possible to pick one that doesn't rely on non-stdlib types (so I guess astropy.units would be out).

That doesn't directly get you the literal syntax for units you focus on, but if units are easier to use, more applications will use them, and perhaps build up momentum for a syntax change. And the syntax change is useless without the library.

I'll try to provide examples of my struggles with units in python but I'm not an accomplished coder at all and don't have much to look at in the way of examples. I sometimes go weeks without writing any code at all, followed by days of nothing but writing code. Python is so painful to use for units I've actually avoided it, so there won't be many examples I can give anyway. Hence my silence in this thread the past few days. I just get really excited at the idea of it being native to the language and am dreaming of being able to use it more often for my every day calculations. Right now I just don't feel confident I can.

My personal preference for adding units to python would be to make instances of all numeric classes subscriptable, with the implementation being roughly equivalent to: def __getitem__(self, unit_cls: type[T]) -> T: return unit_cls(self) We could then discuss the possibility of adding some implementation of units to the stdlib. For example: from units.si import km, m, N, Pa 3[km] + 4[m] == 3004[m] # True 5[N]/1[m**2] == 5[Pa] # True 'Casual' users could also use a star import (despite its pitfalls) and not have to worry about going back and updating the import statement, so I don't think requiring that import would be much of a barrier to beginners. They'd just learn they need that star import at the top of the file as a sort of 'magic spell'. Third-party libraries could provide their own unit classes with additional features and characteristics that you could substitute in by simply changing the import statement and nothing else. To write a custom unit class you would just have to implement an __init__ that accepts a single numeric argument. To enable units like m², the __pow__ magic method would have to be implemented in the unit class' metaclass. The advantages of this seem to me like: 1) no new syntax, just an extra magic method for numeric types 2) batteries included, 3) Won't clutter up the builtins, you have to opt in by using imports 3) simple for third-party libraries to support and extend I can't really see much in the way of disadvantages aside from: 1) aesthetic objections to the use of subscription for this purpose. I personally quite like it because in a way a unit at the end of a number *is* a subscript anyway, so it seems quite fitting to use python's subscription syntax for it. 2) the opposite of advantage 3) above: people actually *wanting* the units to be part of the builtins so that you don't have to use any imports. Depending on your opinion this can be a good or bad thing And if no reasonable implementation of the batteries can be agreed upon, that's fine, that part can be delayed or rejected. On Fri, Apr 8, 2022 at 12:21 PM Ricky Teachey <ricky@teachey.org> wrote:

On Fri, Apr 8, 2022, 2:40 AM Stephen J. Turnbull < stephenjturnbull@gmail.com> wrote:

...

Brian McCall writes:

...

...

...

...

Steven d'Aprano writes:

...

...

you have shown nothing to justify why unit support must be built into the language itself.

I did what I could, but I'm not going to try and justify any more.

That makes me sad, because everybody in the thread acknowledges that improving the Python distribution's support for units is a good idea, but nobody is as enthusiastic about getting it done as you.

Chris Barker's comments about multiple attractive library implementations are well-taken, I think, but I also think that with more focus on getting a satisfactory module into the stdlib, it would be quite possible to pick one that doesn't rely on non-stdlib types (so I guess astropy.units would be out).

That doesn't directly get you the literal syntax for units you focus on, but if units are easier to use, more applications will use them, and perhaps build up momentum for a syntax change. And the syntax change is useless without the library.

I'll try to provide examples of my struggles with units in python but I'm not an accomplished coder at all and don't have much to look at in the way of examples. I sometimes go weeks without writing any code at all, followed by days of nothing but writing code.

Python is so painful to use for units I've actually avoided it, so there won't be many examples I can give anyway. Hence my silence in this thread the past few days.

I just get really excited at the idea of it being native to the language and am dreaming of being able to use it more often for my every day calculations. Right now I just don't feel confident I can. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/LSQQKL... Code of Conduct: http://python.org/psf/codeofconduct/

On Fri, Apr 08, 2022 at 07:20:35AM -0400, Ricky Teachey wrote:

Python is so painful to use for units I've actually avoided it, so there won't be many examples I can give anyway. Hence my silence in this thread the past few days.

Which of the many Python libraries have you tried, and what makes them painful?

I just get really excited at the idea of it being native to the language and am dreaming of being able to use it more often for my every day calculations. Right now I just don't feel confident I can.

You should try Frink. At the very least, that will give you some idea of what is possible with unit calculations, how it might be integrated with a language, and the limitations of units as a concept. https://frinklang.org/#SampleCalculations -- Steve

On Thu, Apr 07, 2022 at 11:18:57PM -0000, Brian McCall wrote:

...

What does it *really* matter which of these you write?

...

that's just arguing over the colour of the bikeshed.

...

you have shown nothing to justify why unit support must be built into the language itself.

I did what I could, but I'm not going to try and justify any more.

But that's my point, you haven't tried to justify why units need to be built-in to the language except to declare that they must and that a library won't cut it. I'm sympathetic to that view, but "Trust me, I'm right!" is not going to sway the core developers or the Steering Council. You're a scientist, think of this as a grant proposal. Convince us.

At the end of the day, units are a core part of science and engineering.

There are many things which are core to science and engineering but aren't part of the core Python language. What makes units of measurements more special than, say, numpy arrays or dataframes? The numpy/scipy/pandas stack is HUGE in scientific Python, and it is not built into the language. nltk is a very big, powerful library used for computational linguistics, and its not built into the core language. If there is something critical in units that requires core language support, what is it?

Scientists and engineers are freaking passionate about units. More and more of them are also being expected to write code to do their jobs. To me that says it's going to happen at some point.

People have been talking about unifying units into programming languages since the 1970s, in Fortran and Pascal. Ada has had support for measurement units since at least 2003 and probably earlier. https://link.springer.com/chapter/10.1007/3-540-44947-7_19 (Sorry, not a free link.) Both F# (2005) and Swift (2014) also support units in the core language. I've also mentioned Frink, and HP calculator "RPL" language supports units. HP has supported them since the mid 1980s. Java, C++, C#, Javascript, Ruby and others all have units libraries. Quote: "These types of libraries do already exist, several hundreds in fact. The problem thus is not the lack of these solutions but the opposite that they are so numerous that it is hard to get an overview." https://onlinelibrary.wiley.com/doi/full/10.1002/spe.2926 So for scientists who want units of measurement support, there are many existing solutions they can use today. Why are those solutions insufficient, and what can be done about it? -- Steve

Greetings, This message is for those that would like to "play" with a more natural looking syntax for units in Python. First, a quick look:

python -m ideas -t easy_units Ideas Console version 0.0.23. [Python version: 3.10.2]

~>> import pint ~>> U = pint.UnitRegistry() ~>> walk = 3[km] + 100[m] ~>> walk <Quantity(3.1, 'kilometer')> ~>> p1 = 1.0[N/m^2] ~>> p2 = 1.0[Pa] ~>> p1 == p2 True == Or, for those that prefer astropy to pint:

python -m ideas -t easy_units Ideas Console version 0.0.23. [Python version: 3.10.2]

~>> from astropy.units import m, km, N, Pa ~>> walk = 3[km] + 100[m] ~>> walk <Quantity 3.1 km> ~>> p1 = 1.0[N/m^2] ~>> p2 = 1.0[Pa] ~>> p1 == p2 True === Or, I simply want to run a script, say # example.py import pint units = pint.UnitRegistry() print(1.0[km] + 2[m]) ===

python -m ideas example -t easy_units 1.002 kilometer

Note that it is "example" and not "example.py" that is run (imported). ====== To try these examples, you need to: python -m pip install ideas and either python -m pip install pint or python -m pip install astropy ## How does it work? "ideas" (https://github.com/aroberge/ideas; documentation at https://aroberge.github.io/ideas/docs/html/) is a library I created a few years ago to allow easy experiments with variations on Python's syntax. When a module is imported (or when some code is run in the modified interpreter), it is first transformed prior to execution. Users of ideas can define transformations that operate: 1. on the source (text) 2. on the AST 3. on the bytecode. If one uses simple source transformations (which is what I did for easy_units), one can see the transformed code prior to its execution in the interactive console, using a "verbosity" flag (-v or --verbosity)

python -m ideas -t easy_units -v Ideas Console version 0.0.23. [Python version: 3.10.2]

~>> import pint ~>> Units = pint.UnitRegistry() # "Units" here is an arbitrary name ~>> walk = 3[km] + 100[m] ===========Transformed============ walk = 3 * Units.km + 100 * Units.m ----------------------------- ~>> p1 = 1.0[N/m^2] ===========Transformed============ p1 = 1.0 * Units.N/(Units.m**2) ----------------------------- ~>> p2 = 1.0[N/m**2] # using ** instead of ^ for Python purists ===========Transformed============ p2 = 1.0 * Units.N/(Units.m**2) # using ** instead of ^ for Python purists ----------------------------- Admittedly, it is a quick hack and may very well be buggy. But it can be fun to use! ;-) André Roberge

Steven D'Aprano writes:

There are many things which are core to science and engineering but aren't part of the core Python language. What makes units of measurements more special than, say, numpy arrays or dataframes?

Arrays and dataframes are data structures, hidden behind the syntax. They can be conveniently referenced and manipulated with functions invoked via existing syntax. This existing syntax is familiar to us from many decades of programming language practice, and we have always accepted it because of the constraint of 1-dimensional computer text. Much of it is extensions of centuries of mathematical practice, from operator symbols to function call notation, to these modern data structures. And that's one thing I love about Python, the ability to use familiar syntax in analogous ways. Applying this line of thought to units, the practice for centuries (at least in English and Japanese) has been to append the unit after the value. But this is a syntax error in Python, and even the 'value[unit]' dodge fails for literal numbers, while it probably isn't needed often for variables (I would probably even consider it bad style). We can construct a Unit class, and use the multiplication operator to combine a "bare" number with the unit, but this doesn't feel right to naive users. To me it feels like multiplying a number by a list. What I ideally want is two parts of a coherent whole, like real and imag. (Note: This does not bother me in practice at all, I'm trying to empathize with the folks whole say they can't stomach Python's approach to units at all.) Furthermore, there's another problem: units "should" have their own namespace, almost like keywords. But it's much more complicated than keywords, because (1) there are many more potential collisions, both between ordinary identifiers and units ('m' as an integer variable vs. 'm' as a unit) and among units ('A' for ampere and 'A' for Angstrom), and (2) the units namespace should be extensible. Both of these issues (natural language practice and namespace) can be most fully addressed with syntax that allows an optional identifier expression to be placed directly after a literal or identifier, and enforcing the semantics that this optional identifier expression must be composed of registered units and only the allowed operations (* and /, I guess). Invalid operations would be SyntaxErrors, unregistered identifiers would be RuntimeErrors. I think that one way both issues can be addressed without syntax is to take a package like units, add "repertoire attributes", so we can write things like this import units u = units.si.modifiable_copy() # the SI repertoire is read-only u.register_unit('frob', 'Fr', composed=u.foo/u.m, doc='Frob is a devo unit invented by A. Panshin.') if 12*u.mm * 42*u.MFr == 502*u.foo: print('Well done!') That would work fine for me. But I can see why somebody who frequently uses interactive Python as a scientific calculator would prefer to write if 12 m/s * 42 s == 502 m: print('Well done!') with the base SI repertoire (a dozen or so prefixes and 7 units) in builtins. As far as I can tell, that's the whole argument. Steve

Warning: serious linguistic hacking follows. I tried to be careful in writing, please be careful in reading. Corrections welcome. Ethan Furman writes:

On 4/9/22 21:17, Stephen J. Turnbull wrote:

...

if 12*u.mm * 42*u.MFr == 502*u.foo: print('Well done!')

Part of the argument as well, I think, is that the top expression would be parsed as:

((12 * u.m) * 42) * u.MFr

which, if actually equal to 502*u.foo, is dumb luck.

It's actually equal to 504*u.foo, I shouldn't do multiplications larger than 12 * 12 in my head. But yes, the correct answer is (12 * 42) * u.foo, if I could only do arithmetic on integers! I guess you could call the associative law of multiplication "dumb luck", but most mathematicians will consider that hate speech. If the unit class is designed correctly (the units package is designed correctly), both the associative and commutative laws of multiplication hold. The only gotcha as far as the value is concerned is that if you put in divisions such as u.m/u.s, then you often will need parentheses. But that's true for ordinary arithmetic as well. There would be a problem if the LHS were 12*u.mm / 42*u.MFr. That's actually nonsense in a units-aware world. Parentheses are required: 12*u.mm / (42*u.MFr). The "we demand syntax" crowd wants the "add unit" operation to have higher precedence than numerical multiplication and division. Hmm, unfortunately both '@' and '%' have the same precedence as '*' and '/', but we could make the precedence more natural by using '**' at the cost of the intuition that a unit is just a quantity (object with both value and unit attributes) with value 1. I'm not sure that intuition helps the "we demand syntax" crowd, though. Another way to put the issue is that libraries like units don't provide units, they provide quantities. You can create a quantity foo that acts like a unit by giving it the value 1, but 10*foo is of the same type as foo. It just has value attribute 10. Again, that doesn't bother me, but I suspect that the "we demand syntax" crowd will feel queasy about the idea that 'nm' *is* '1 nm'. For them, 'nm' needs to be notated with a value to be a quantity. I don't want to put words in anybody's mouth. If Brian or Rickey disclaims that interpretation, they're right. If they think it has expressive value but needs to be amended, they're right. I'm just trying to provide words to express what the need is here.

On Mon, Apr 11, 2022 at 11:33 AM Ethan Furman <ethan@stoneleaf.us> wrote:

On 4/10/22 21:33, Stephen J. Turnbull wrote:

...

I guess you could call the associative law of multiplication "dumb luck", but most mathematicians will consider that hate speech.

My apologies for not understanding your example. The counter example I had in my head, and should have written down, was something like:

15mpg * 7l == how many miles?

where

mpg = miles per gallons l = litres

I'm pretty sure the answer there is not 105.

Really? ;-) ;-)

...

...

import pint ureg = pint.UnitRegistry() mpg = ureg.define('mpg = 1 * mile / gallon') dist = 15 * ureg.mpg * 7 * ureg.l dist <Quantity(105, 'liter * mpg')>

It is 105 ... but in some weird distance units.

...

...

dist.to(ureg.miles) <Quantity(27.7380655, 'mile')>

Or, in a more readable way! ;-) ;-)

python -m ideas -t easy_units Ideas Console version 0.0.30. [Python version: 3.9.10]

...

...

import pint ureg = pint.UnitRegistry() ureg.define('mpg = 1 * mile / gallon') dist = 15[mpg] * 7[l] dist.to(1[mile]) <Quantity(27.7380655, 'mile')>

André Roberge Thought: I should probably make it even easier to convert units within ideas...

-- ~Ethan~ _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/OGHZSH... Code of Conduct: http://python.org/psf/codeofconduct/

Ethan Furman writes:

On 4/10/22 21:33, Stephen J. Turnbull wrote:

...

I guess you could call the associative law of multiplication "dumb luck", but most mathematicians will consider that hate speech.

My apologies for not understanding your example. The counter example I had in my head, and should have written down, was something like:

15mpg * 7l == how many miles?

Now it's my turn to not understand the point of this example. Are you arguing Chris A's point that in some applications you want those conversions done automagically[1], and in other applications you want to get a YouSureYouMeanThatBoss? Exception[2]. :-) Footnotes: [1] American you just bought a car in Detroit MI and it still has the EPA sticker "15mpg" on the window, and now you're in Windsor ON (Canada) looking at the cost of the 7l you put in and wondering if you can get back home to Ann Arbor MI on that. [2] Building a Mars lander for NASA.

On Tue, Apr 12, 2022 at 11:27 AM Christopher Barker <pythonchb@gmail.com> wrote:

...

...

I guess you could call the associative law of multiplication "dumb

...

luck", but most mathematicians will consider that hate speech.

My apologies for not understanding your example. The counter example I had in my head, and should have written down, was something like:

15mpg * 7l == how many miles?

Using pint:

In [76]: U = pint.UnitRegistry()

In [77]: (15 * U.miles / U.gallons * 7 * U.liter).to('miles') Out[77]: 27.7380654976056 <Unit('mile')>

A bit verbose, perhaps, but to me clear, and the operator precedence rules seem to "just work".

And it you want it a tad less verbose, you can give some of those units names:

In [78]: mpg = U.miles / U.gallons In [79]: l = U.liter

In [80]: (15 * mpg * 7 * l).to('miles') Out[80]: 27.7380654976056 <Unit('mile')>

My question for the folks that want units built in to Python is "what's so hard about that?

Ricky wrote:

"Python is so painful to use for units I've actually avoided it,"

Really? have you tried pint? or anything else? what is so painful about this?

-CHB

-- Christopher Barker, PhD (Chris)

I will try to finish my email about this I started writing a week ago! --- Ricky. "I've never met a Kentucky man who wasn't either thinking about going home or actually going home." - Happy Chandler