[AstroPy] Draft specification for PyFITS functional interface

Perry Greenfield 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[1]). 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...

shufits er...

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 mailing list