[AstroPy] Co-ordinating Python astronomy libraries?

[Johann Cohen-Tanugi]

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.

Johann
> 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.
>>      
>
>