[AstroPy] Co-ordinating Python astronomy libraries?

[Erik Tollerud]

Hi James and Wolfgang,

> Classes and data structures seem to be another common theme in this
> thread that probably deserve more discussion. A few people have
> mentioned time and co-ordinates. I was wondering whether Anne or
> someone else has been following the NumPy datetime discussion and
> whether that's at all relevant (since I know she is more active on
> that list than I am)?

I definitely agree classes like this are a good way to make scientific
codes much easier to work with and cleaner to manage.  I would also
like to note that I've already implemented a pretty complete and
documented set of coordinate classes, transforms between them, and the
related time-keeping in astropysics (see
http://packages.python.org/Astropysics/coremods/coords.html and
http://packages.python.org/Astropysics/coremods/obstools.html).  This
is in pure python (with numpy arrays, of course) and are ready to be
subclassed right now if you want to use them.   It's also dead-trivial
to write transforms back to standard coordinate types.  It's not as
full-featured as pyephem right now, but is pure python, which makes
installation/distribution easier, and crucially in my view, easier to
extend.  (To be clear this is not intended at all as a bash against
pyephem - just a different design choice, as Brandon himself pointed
out)

As for the question, I'm pretty sure the datetime enhancements are
supposed to go into numpy 2.0, because it requires an ABI change...
I've never been clear on exactly when that's going to be released as
it's been "soon" for some time, but I think they're shooting for
end-of-summer or fall? (note that numpy 2.0 will also support python
3.0 along with a paralell scipy release).  But I don't quite
understand what the connection is between that and
coordinate/time-keeping classes...?  The datetime class in standard
python works just fine for individual objects...


> That sounds convenient. Apparently several people/groups are working
> on these kinds of high-level objects and some standardization may
> indeed be helpful, otherwise I'll be using AstroData for part of my
> processing and then find I need to pick apart my object to construct
> your 1D spectrum from pyspec, then do something different again from
> Astropysics or PyEphem and so on. A few standard classes would
> probably help significantly in providing a good focal point.

Agreed completely on this, and that was my motivation behind making
astropysics as an integrated set of packages... For example, the
spec.Spectrum class in astropysics uses phot.Band objects
(representing photometric bands) to do various calibrations (and
optionally vice versa), and that's not possible if there isn't a
well-documented API (hence I had to write them both along with their
API).

The main problem is how to integrate the base classes in a way that
makes everybody happy and doesn't leave anyone thinking their work is
ignored or uncredited, as perhaps shown by my perhaps not-so-subtle
advertisements in the comments above... I can definitely see ways to
integrate, say, pyspec with the astropysics Spectrum class, but it
would be a fair bit of work given the rather different internals.  Or
would it be better to initially ignore all previous work, settle on a
simple API, and then leave it to packages to implement the details?
Although that seems problematic to me as the details are a lot of what
matters in this sort of highly numerical work...



-- 
Erik Tollerud