[AstroPy] [astropy-dev] Coordinates subpackage - request for help

Perry Greenfield stsci.perry@gmail....
Fri Nov 16 12:19:09 CST 2012

On Nov 16, 2012, at 12:41 PM, Demitri Muna wrote:

> Hi,
> I would be in favor of using AST as a back end for several reasons.
> * There is value to using a single piece of code over reimplementing a new one. From a user's perspective, there is no value in a pure-Python implementation over a C-based one. Those are details they should not be aware of, and our aim here is to make them agree to as high a precision as possible. Work is not duplicated - we have scant resources and a monumental task ahead (astropy).
This certainly true, but it isn't always quite that simple (i.e., other factors enter into the question also).

> * The *most important thing to me* is a clean, easy to use API. (Aside from accuracy. :) I see no reason why this has to be sacrificed at all, so while there might be a little pain up front for us to write the glue code, I think that's fine.
Likewise, whether a good python api can be layered sometimes is not as easy as it sounds. It depends sometimes on how one coordinates [er] activities between the two that can get complicated, particularly if there is a lot of state involved. I'm not saying it's a problem here, but it isn't always as simple as it sounds. Another complication is when you want to extend the library. Do you do that in C or Python? If in Python, will the extensions carry through to the old C code? It can get messy.

> * I haven't ever used (or seen) pyast, but my knee-jerk reaction is that I don't want any layer at all between the C AST and astropy code.

> * Getting lots of features "for free" seems like a huge win, and even if the astropy classes don't expose them yet, it will be far easier to write a good API than to reimplement the functionality.
For other reasons (alluded to in a separate email), I'm not sure the WCS functionality is easily used the way we would like it to be.


More information about the AstroPy mailing list