[AstroPy] Co-ordinating Python astronomy libraries?

[Brandon Craig Rhodes]

James Turner <jturner at gemini.edu> writes:

> At SciPy 2009 ... we discussed the fact that there are now a number of
> astronomy libraries for Python floating around and maybe it would be
> good to collect more code into a single place.  People seemed
> receptive to this idea and weren't sure why it hasn't already
> happened...

Hey, James!  Thanks, I've now joined the AstroPy mailing list.

The reason that I have never really considered trying to merge PyEphem
with any other astronomy package is one of architecture.  The "libastro"
library from inside of XEphem, which PyEphem tweaks and then places
behind a Pythonic interface, is designed to use all of its own types
(either C "doubles" or structs built from doubles) for inputs like
dates, locations, and orbital elements, and outputs like coordinates.
It is its own little universe, software-wise, and PyEphem remains
easiest to keep working when I leave the XEphem code in a nearly
pristine state.  This advantage would be lost if I gutted the pure-C
astronomy routines to read and write data to, say, NumPy arrays instead,
or any other third-party data format.  The fun of using PyEphem is the
efficiency of asking a question, getting a date back, then being able to
plug that date right into your next calculation because it's already a
floating-point number of the sort that "libastro" uses internally for
dates.

Another reason that I have never had dialog with another project about
merging or sharing code is that most of the astronomy packages that I
see appear for Python (I do go browse the other astronomy packages on
PyPI from time to time) are doing entirely different things than
figuring out where Jupiter is on a given night: they're doing things
like image processing, which are entirely different problems that use
entirely different data structures.  Even an orbital mechanics
simulation would probably use quite different data structures (it would
hopefully include momentum, for example!) from the RA/declination-based
"structs" that lie behind the Jupiter(), Mars(), and other objects in
PyEphem.

That's not to say that I've never thought of trying to start over with a
pure-Python astronomy library.  I even, recently, thought through how I
would improve upon the PyEphem object set if I had the chance.  It would
also be nice if routines were implemented in Python - right now, PyEphem
can only be used with C-Python but not easily with IronPython; that
would not be the case if everything were written in Python.  (Though,
the routines would obviously be much slower until C-Python gets a JIT
compiler!)

But to take these steps would be to essentially start over with a new
project, and the point of PyEphem was quite different: to take a robust,
already-working, mature library for computing planet and comet
positions, and make it efficiently callable from Python.

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon