On 19 September 2016 at 07:23, Oliver Lemke <oliver.le...@uni-hamburg.de> wrote:

> Lukas and me had a discussion on how to handle the functions that require 
> pint. We would like to turn the units/pint functionality into a subpackage of 
> physics. The idea is that all functions directly under physics are operating 
> on SI units without any pint dependency. Functions that do support units 
> should go into the units subpackage. For functions in physics, small wrapper 
> functions can be added in the units subpackage that use pint to convert the 
> inputs to SI units and then call the plain function from the physics package. 
> Is that ok with you?

That makes a lot of sense.  Specifically, I think when we say "SI
units" we mean "base SI units", which is good for consistency even
though it's sometimes unusual (for example, g/mol is more common than
kg/mol).  How do you want to handle functions/classes outside the
physics/ subpackage?  My HIRS reading routine by defaults uses base SI
frequency radiance [W / sr / m² / Hz], but this is very unusual and
confused two colleagues already, so I added an option to return what
everybody else uses, [W / sr / m² / cm^-1]; I use pint to convert
between the two (a third alternative would be [W / sr / m], likely to
confuse equally if not more).

typhon.mi mailing list

Reply via email to