[AstroPy] [astropy-dev] ANN: Astropy v0.1

Joe Harrington jh at physics.ucf.edu
Tue Jun 19 14:04:38 EDT 2012

I'm happy with that, but it should be clearly documented in a central,
well-known place, so that people know what they can and can't depend on
to be stable.  If I'm writing software for a spacecraft project or
instrument calibration pipeline that MUST be long-term stable, I might
choose to use pyfits (now stable) but not NDData (not stable).  A
student working on a homework assignment might safely use NDData.


On Tue, 19 Jun 2012 13:40:31 -0400 Wolfgang Kerzendorf
<wkerzendorf at gmail.com> wrote:
> Hi Joe,
> I would think that many other things (NDData as one prime example) are
> still i> n high alpha. I think with many of these new functions we
> will have t> o iterate somewhat between developing - usage feedback to
> get to > a stable interface. I think this release shows relatively
> well what w> ill be there (there's likely going to be a class called
> nddata) b> ut that their interfaces might change.
> Cheers
>   W
> On 2012-06-19, at 1:25 PM, Joe Harrington wrote:
> >> Nevertheless, you can already make use of the existing functionality,
> >> which is fully tested. Key features include:
> > 
> > Excellent news!
> > 
> > The question "when to switch" comes up.  I'm sure some parts (pyfits,
> > pywcs, etc) are very stable and the calling syntax, data objects,
> > etc. won't change in the future.  I'm equally sure some things are still
> > highly alpha.  Would it make sense to provide a list
> > (help(astropy.stability())?) that lays out what you can depend on and
> > where you should or might expect changes?  Or, is there a pathway from
> > public code development with public usage and the understanding that
> > it might change, to freezing it and including it in astropy, such that
> > astropy is only mature, stable code?
> > 
> > --jh--

More information about the AstroPy mailing list