[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.
--jh--
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