[AstroPy] Co-ordinating Python astronomy libraries?
Mon Jul 19 04:11:40 CDT 2010
On 07/19/2010 08:50 AM, Erik Tollerud wrote:
> Just one clarification I'd like to make - I would agree that the
> smaller targeted packages are probably a good idea in this situation,
> but the point I'm making is that coding standards for all of the
> packages under the umbrella project should be consistent, and that's
> easier to do from the group up. Things like the use of capital
> letters for the beginning of class names, consistent use of the *same*
> package to do tasks that are the same (like my model fitting example),
One package for any model fitting? That does not seem very reasonable.
Even xspec does not come close to this!
Model fitting is a ultra high level analysis tool. I do not think that
we are at the stage that we can contemplate this kind of issues.
I am doing single photon high-energy astrophysics (Fermi LAT data) : I
can assure you that my spectral needs are totally different from a CCD
based spectral analysis "a la" X-rays.... But I still need a seamless
way to interface WCS and easily visualize astronomical data, with
contour overlaid etc..., whatever the underlying system of coordinates
used or the projection method requested.
> identical style for documentation, etc. Without these consistencies
> it becomes very difficult for the user to understand anything (or the
> new developer to expand anything), so they'll just give up and use
> something else.
> But definitely good to see momentum in this direction!
>> I agree and disagree. I think that we need to have a strict API, that
>> assures compatibility between the different tools. Even if we improve the
>> coordinate objects, then this should still work. On the other hand, I think
>> we should strive for wide acceptance, as more users means more developers
>> and less time for each individual. And thus a user wanting to use the
>> astropy time objects, may want to only install this time object and not a
>> big package. Also if someone has a better time object with the same API it
>> is easy to replace the old one.
>> I for one think that for this opensource and multiuser development small
>> packages (that speak the same parameter language of course) is better suited
>> for the task than monolithic development.
More information about the AstroPy