Possible use for unit interpretation

[mhvk]

Not sure if this is the right place to raise this possibility, but I think the tag functions might have much broader use, which may be of interest to mention in an "other uses" section or so.

For instance, there are a fair number of packages providing physical units and quantities (I'm a maintainer of astropy's units package myself), and an annoyance has been how to compactly add units. Right now, we might write something like,

import astropy.units as u

asv = 42 * u.km / u.hour

which is readable enough, though means the brain has to jump steps to reinterpret. Some people therefore choose to typically do,

from astropy.units import Unit

asv= 42 * Unit("km/hour")

where the string is closer. With your tags, it seems that something like

asv = 42 * u_"km/hour"

would trivially become possible (from a quick check on the jupyterlite notebook, it looks one cannot override the these days useless u prefix, which might have been even nicer...)

p.s. Obviously more helpful with units like "erg/(s cm2 Hz)"

p.s.2 I feel I actually saw this suggestion on python discussion for stdlib at some point, but cannot find that. Anyway, my search let to the idea of tag strings here.

[pauleveritt]

First, this is a perfect place to have this conversation. Thanks for taking the time.

Your usage sounds good to me. Reminds me a bit of @jimbaker interest in logging. Meaning: instead of some big DSL with a lot of grammar, just a one-liner that wants to get data from the scope it was called from.

One point to remember: tag strings don't have to return a string. They could return something with an __str__ but also handle multiplication and other operations. Which might give you access to the 42.

We have a companion site where we hope to do tutorials, other examples, etc. Interested in joining us there and poking around?

FYI, over there you'll a link to a JupyterLite instance with a working version of the tag strings implementation, thanks to @koxudaxi with help from Hood. Koudai also has there pre-built Docker images. Dave Peck has gotten us going with GitHub CodeSpace.

[mhvk]

Thanks! I had indeed tried the jupyterlite with a very simple def flt(*args): return float(args[0]) which clearly worked fine and that was what made me think the unit should work just as easily.

In our case, just returning a Unit instance would suffice to make things work - it already knows how to multiply itself with a number or array to create a Quantity (i.e., u_"km/s" would really just be syntactic sugar for u.Unit("km/s") for our case).

The logging case indeed seems similar, but in our case I don't think we need any information from the scope (which is a beautiful thing in your scheme!). As said, it would just be syntactic sugar, but really nice one to have! (and maybe there will be a nifty usage for the scope after all...).

Anyway, as said on top, perhaps useful in the PEP as a very different example of things that this would enable.