Pint: a Python units package

[Michael Droettboom]

Just found out about "Pint", a Python-based units package on python-announce today.

http://python-in-the-lab.blogspot.com.ar/2013/05/a-pint-day.html

Some interesting points to compare and contrast with astropy.units:

1) It puts all of the units in a namespace object rather than a module as we do.  Some of the discussion about moving non-scientific units out of the default in #1073 may align with this.  By putting things on an object, you can do things like bringing sets of units in and out of the namespace easier than faking it with a module dictionary as we do now.

2) It overrides Numpy functions to be unit aware, such as the trig functions, as we plan to do in #955.

3) It supports non-multiplicative conversion functions, such as would be needed to convert between Kelvin and Celcius.  Is this something that would be useful for us?

4) It doesn't seem to support equivalencies, decomposing/composing units, mapping units to other units etc.

I'm not proposing merging/using this etc. -- I think there's an advantage of focusing on astronomy-specific needs first has its advantages, though there's obviously some general utility to all of this.

Any other thoughts?

Mike

--
Michael Droettboom
http://www.droettboom.com/

[Perry Greenfield]

On 5/13/13 9:34 AM, Michael Droettboom wrote:

>
> 3) It supports non-multiplicative conversion functions, such as would be needed to convert between Kelvin and Celcius. Is this something that would be useful for us?
>

I've never been persuaded that this is an important use case. It's a bit of a odd situation with degrees of temperature. I argue that most computations with degrees are with differences in temperature, in which case the offsets don't matter. Otherwise it is simply an equivalency I think (and could that be set up to handle it?). But I can't say I've given it any deep thought.


Perry

[Michael Droettboom]

Certainly an equivalency could be added to handle degrees of temperature -- we can probably throw that in and then experiment with/discuss making those equivalencies "default".

Mike

Perry


--
You received this message because you are subscribed to the Google Groups "astropy-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to astropy-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Erik Bray]

I wonder if there is some level on which we could cooperate with this
project. Not merge necessarily but at least share some of the more
useful common functionality like the overriding of Numpy functions.
Also +1 to unit namespaces. I think we should copy that. I also
still like being able to import units at least from a default
namespace, but we implement that as an importer hook rather than
hacking directly on the module namespace. That might also alleviate
some of the circular import problems, though I admit I haven't given
the details much thought yet.

> --
> You received this message because you are subscribed to the Google Groups
> "astropy-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to astropy-dev...@googlegroups.com.

[Erik Tollerud]

> 1) It puts all of the units in a namespace object rather than a module as we
> do.

+1 from me, as well. After all, they are one honking great idea --
let's do more of those! :) It could nicely address some of the issues
we've been encountering with the proliferation of units. It would
also enable the ``q.to('extragalactic')`` and similar usage.

> 2) It overrides Numpy functions to be unit aware, such as the trig
> functions, as we plan to do in #955.

Yeah, this is good to know about - it may help with some of the issues
in #955 to look at their implementation.

> 3) It supports non-multiplicative conversion functions, such as would be
> needed to convert between Kelvin and Celcius. Is this something that would
> be useful for us?

I agree with Perry this is not terribly important given that it's
really only for temperature. It's not necessarily *bad* if someone
wants to add it, but I'd consider it "low priority" (and it may not be
worth the trouble even if someone does add it).

--
Erik