[AstroPy] Co-ordinating Python astronomy libraries?

[Perry Greenfield]

A  SLALIB wrapper would be great (and justifiably part of an astronomy  
toolset).  Of course, the problem is with SLALIB itself since it  
doesn't have an open source license. (That's something that other  
would have to obtain and install separately). That's the big drawback.

Perry

On Jul 6, 2010, at 12:39 PM, Anne Archibald wrote:

> Hi,
>
> I use a couple of python astronomy libraries; the python bindings to
> the pulsar search library PRESTO, and the python bindings to the
> FORTRAN library SLALIB. Both were written by Scott Ransom; obviously I
> can't speak for his motivations in writing them.
>
> I think I follow a fairly common pattern, though: the libraries I use
> are fairly thin wrappers of existing compiled code, and in one case
> the code is very domain-specific. So combining them somehow with other
> python libraries would involve either linking together a huge mass of
> different compiled libraries with overlapping functionality, or
> modifying the underlying libraries. Either one would be a tremendous
> amount of work.
>
> That said, I use SLALIB for a simple coordinate conversion (in fact I
> use it to replicate exactly another coordinate conversion done in
> compiled code, so this is kind of theoretical), so in principle if
> there were a generic python astronomy library that covered this (I
> didn't find one) I might have used it instead. The PRESTO code, not so
> much; it includes some extremely specific pulsar searching code that
> can't reasonably be included in existing python libraries.
>
> What might be nice would be a "standard" list of data types for common
> objects, so that at least one could pass objects from one library to
> another. RA and Dec objects, perhaps, or time objects. Of course time
> objects would be a massive headache if you wanted them to be
> generically usable, since they'd need to be good to the nanosecond
> over a span of millenia (so doubles won't cut it), support
> UTC/TDB/TAI/etc. as well as MJD/sidereal/GMT/local time
> representations... Nevertheless, compiled code (and thin wrappers)
> tend to just take doubles and rely on the user to keep track of what
> they mean, while a more pythonic and less error-prone approach would
> use python's type system to catch many errors.
>
> Anne