Consistent `str` formatting (with units and transformed units)

[sadielbartholomew]

When a units object is transformed by some operation, such as at least (as tested) a 'power' operation or as the denominator in a division operation, the formatting of the units can change in form: originally, before if the operation it uses ** to indicate preceding exponents and spaces to delimit the unit components, then after it uses numbers straight after the unit symbol to indicate an exponent value, with dots to delimit the unit components, as illustrated:

>>> u = cfunits.Units("K m**2 kg**-1 s**-1")
>>> print(u)
K m**2 kg**-1 s**-1
>>> print(u**2)
m4.kg-2.s-2.K2
>>> # And the repr() includes the str() for this so similarly changes: <Units: K m**2 kg**-1 s**-1> -> <Units: m4.kg-2.s-2.K2>

Upon a little further investigation, any transform that is valid and produces new units seems to change the repr like above. So there is formatting inconsistency.

It seems the dot-delimited and symbol number form (e.g. m4.kg-2.s-2.K2) is the form that is returned by default, for example using that as the original form retains consistency:

>>> u = cfunits.Units("K.m2.kg-1.s-1")
>>> print(u)
K.m2.kg-1.s-1
>>> print(u**2)
m4.kg-2.s-2.K2

So it seems the issue boils down to (unless I am missing some related point/subtlety) alternative valid formatting, such as the space-delimited double-asterisk form, being an accepted way of inputting units that is rendered as entered when the unit was initialised.

Ideally, we can have consistent formatting for the units always, which would mean, as far as options go as far as I can see, that we either:

• always represent units with consistent formatting from initiation: so u = cfunits.Units("K m**2 kg**-1 s**-1") would, when printed, instead return K.m2.kg-1.s-1 rather than the K m**2 kg**-1 s**-1 it returns now; or
• have formatting preserved before and after operations, so whatever formatting style we have for the original, we use for the transformed version, so the same case of cfunits.Units("K m**2 kg**-1 s**-1") would, when squared, have its str() representation converted to conform with the original to m**4 kg**-2 s**-2 K**2.

As noticed from the quick summary Notebook of the CF Tools Training (https://github.com/NCAS-CMS/cf-tools-training/blob/master/new_course/quick_summary/cf_data_tools_summary.ipynb).

[davidhassell]

Hi Sadie,

The way things are at the moment, we are at the whim of the Udunits C library on this. The question is, how much can we control that whim? We've the names and definition to have some control over the string name stored in the unit:

In [22]: Units("K.m2.kg-1.s-1")._units
Out[22]: 'K.m2.kg-1.s-1'

In [23]: Units("K.m2.kg-1.s-1", names=True)._units
Out[23]: 'meter^2-kilogram^-1-second^-1-kelvin'

But there's no flag to say what the format is. However, we might be able to store the fact that names or definition has been applied, and also apply that formatting to a combined result.

As to persuading Udunits to create create the other aspects of formating, I don't know how to do that, becuase the above two units both have the same ut_unit - which is the definition of the unit according to the Udunits overlord:

In [26]: Units("K.m2.kg-1.s-1")._ut_unit
Out[26]: 94743598472688

In [27]: Units("K.m2.kg-1.s-1", names=True)._ut_unit
Out[27]: 94743598472688

(This ut_unit integer is arbitrary, and will vary for the same unit defined in different Python sessions.)