[AstroPy] Re: functional interface for PyFITS?: foo.fits[2]

Victoria G. Laidler laidler at stsci.edu
Tue Mar 22 11:22:57 CST 2005

I've been googling a bit and have not yet found whether the FITS 
standard either mandates or recommends support for the 'foo.fits[2]' 
syntax to specify the extension.

In addition to ftools and ciao, IRAF also supports this method for 
filename specification.

PyFITS does not support it presently.

Andrew Ptak wrote:

>I missed the original post so I'm sorry if this was already mentioned, 
>but in fairness I just want to add that this format for selecting 
>extensions has been in use for a while in high-energy fits software, most 
>notably ftools and ciao.  For both of these, you can give either the name 
>of the extension or the extension number in brackets.  So that format is 
>"natural" for some of us, and might help with converting shell scripts to 
>pure python.  I wonder if there is anything in the fits standard 
>concerning filenames. But of course this is a minor issue and not allowing 
>it would be ok.
>Andy Ptak
>On Tue, 22 Mar 2005, John Blakeslee wrote:
>>>>img=getdata('foo.fits[2]')  for the 2nd extension, as a valid alternative
>>>Be careful here.  How do you distinguish that from a file whose name
>>>is literally foo.fits[2]?  And if you do 'foo.fits'[2], how do you
>>>distinguish that from the second element of a string array (bar, in
>>>this case): getdata(bar[2])?  The first is contrived but possible in
>>>the grand universe of file-naming schemes.  The second I use *all the
>>>time* to address a list of filenames in sequence.  Stick with
>>>getdata('foo.fits', ext=2).  It's just a few extra characters longer
>>>than the shorthand, and is much clearer.
>>I want to agree whole-heartedly with this comment!
>>We use pyfits a lot and find it amazingly useful,
>>and the syntax fairly clear and consistent.  Allowing
>>something like 'foo.fits[2]' in a function call to 
>>refer to the 2nd extenstion in the file would open
>>a Pandora's box of inconsistency and confusion, or 
>>at least set a very bad precedent.
>>AstroPy mailing list
>>AstroPy at scipy.net
>AstroPy mailing list
>AstroPy at scipy.net

More information about the AstroPy mailing list