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

[David Berry]

On 16 November 2012 17:41, Demitri Muna <demitri.muna at gmail.com> 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).
>
> * 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.
>
> * The 12MB size I think is trivial, and if it takes a few more minutes to compile, I think that's fine. I would also advocate hosting/distributing prebuilt binaries. The number of versions needed for the whole Mac universe is small and easy to maintain, the more popular Linii can be made, and anything else should compile. If it doesn't, we push the issue back upstream and not fix it ourselves. David, what are the external dependencies? Can the library be built as a distributable static library?

AST uses sofa and pal (github.com/Starlink/pal). These come bundled
with AST, but it is possible to use external versions of these
libraries instead (that was a requirement for it going in the Debian
repository). It has no other external dependencies. It can be built as
a static library.

> * 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.
>
> * I would like to get Erik's thoughts on the question of providing a means to extend transformations. David, are there hooks in AST to do this? I don't know what it would entail.

Obviously, AST is open source, and so I'm  very happy for others to
contribute to it. If a new class of Mapping is needed,  an option
would be to write it in C and add it directly into the AST library so
that other non-Python users of AST get the benefit as well.

I've never given much thought to the idea of providing a scheme that
allows other external libraries to extend AST classes, but it is
clearly something that would be valuable, and could probably be done.

David