[AstroPy] Draft specification for PyFITS functional interface
perry at stsci.edu
Wed Mar 30 14:42:47 CST 2005
On Mar 30, 2005, at 3:07 PM, Nor wrote:
> Keeping the two separated would be my preference as well. It would
> leave pyfits unpolluted by the "quick and dirty" high level interface
> (qpyfits? :-) )
> On Mar 30, 2005, at 2:42 PM, Paul Barrett wrote:
>> I'm wondering if these convenience functions aren't better off in a
>> separate python module that imports pyfits. This approach would keep
>> the pyfits interface simple and objected-oriented, and would signal
>> that the procedural interface is being used. Command line versions
>> of these convenience functions could also exist, so that users could
>> easily extract information from a FITS file.
These are good points, the problem then that has to be faced is that a
choice has to be made regarding filename syntax since I don't think
having 3 separate modules is sensible (to include or not include
handling of cases like input.fits). My read is that if there are
only two modules, it must be included. What say those that despise this
usage? Which is worse:
oo-only pyfits and iraf/cfitsio-convention-contaminated xxxfits?
oo+functional pyfits and iraf/cfitsio-convention-contaminated xxxfits?
As for names, hmmm...
I think I find qpyfits getting too long.
Also, the interactive/functional version I think should either not
expose the pyfits.open function or it should rename it (fitsopen?) so
that from xxxfits import * may be used by those that wish to.
More information about the AstroPy