[AstroPy] Draft specification for PyFITS functional interface

[Perry Greenfield]

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

ifits
pifits
qfits
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.

Comments?