[AstroPy] Co-ordinating Python astronomy libraries?

[Perry Greenfield]

Again, I don't see  dependencies on other software as a reason to keep  
packages out. This is a good example of this (sextractor, slalib), etc.

Perry

On Jul 3, 2010, at 6:24 PM, Brandon Craig Rhodes wrote:

> 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
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy