[AstroPy] Draft specification for PyFITS functional interface

Perry Greenfield perry at stsci.edu
Wed Mar 30 20:39:15 CST 2005

OK, I'm persuaded that the right thing to do is only have one module: 

1) the functional interface will support keywords specifying whether 
the the
iraf convention will apply or not.

2) Rather than make this value default to one value or another within 
the function,
we'll try going with a module default that a user can use to change 
There are drawbacks to this (a user can cause the behavior of scripts 
assuming the other default to behave differently if they really depend 
on this
distinction), but I think one camp or the other is going to find using 
keyword interactively to be a major hassle to bypass the default 
I'm not crazy about adding extra sets of functions for the other 
We can always do that later if this solution proves to be unworkable.

3) we will add a fitsopen function to alias to open and use the __all__
mechanism to hide open when doing a "from pyfits import *" so that open
does not override the built-in open.

I hope that settles it (fingers crossed).


On Mar 30, 2005, at 5:14 PM, Peter Erwin wrote:

> At 3:08 PM -0500 3/30/05, <laidler at stsci.edu> wrote:
>> I agree with Peter - to my mind, one of the strengths of
>> Python is that it supports both functional and object-oriented
>> programming, so that it's easy and painless to switch back and
>> forth or mix them as the need arises. In an interactive
>> session, I might be very likely to use the functional routines
>> as long as things are going as I expect, and then want to
>> switch to the OO ones for cases where things are going wrong
>> and I need more direct control of the file's innards.
> Well, obviously, I agree with this ;-)
> It's actually what I was going to add, but you beat me to it -- one
> of the things that makes Python so useful is its flexibility and *lack*
> of forced adherence to a particular programming style.  Complaints
> that it would be "polluting" the pyfits interface make no sense to me,
> I'm afraid.  (My personal perspective is that it would make pyfits
> *more useful* and easier to start using; I've been slightly leery of
> digging into pyfits because an object-oriented approach seems
> slightly excessive for the things I usually want to do with FITS 
> files.)
> Many of the Python standard libraries are similarly "unclean", and
> more useful because of it.
> As for the ".fits[1]" issue -- I'd find it somewhat convenient to be
> able to use that syntax, but it's not a big issue for me.  So if you're
> looking for votes on:
> At 3:42 PM -0500 3/30/05, Perry Greenfield wrote:
>> Which is worse:
>> oo-only pyfits and iraf/cfitsio-convention-contaminated xxxfits?
>> oo+functional pyfits and  iraf/cfitsio-convention-contaminated 
>> xxxfits?
> then my votes is that the *first* in that list is worse...
>    -- Peter

More information about the AstroPy mailing list