[AstroPy] Re: functional interface for PyFITS?

[Andrew Ptak]

Right, I just was mentioning that there was existing usage of the bracket 
approach, even though to some it seemed ridiculous, and some very minute 
population might expect it if it were allowed by the fits specification.  
Of course anyone using pyfits would be able to use whatever is adopted 
without any problem.  Maybe something actually worth discussing (and I 
remember some traffic along these lines a little while back, plus I only 
skimmed the initial posts on this) is to what extent to emulate idlastro. 
Many astronomers coming over to python will be doing so from IDL and 
that library.  It would be cool to be able to run the following:
data =  readfits(filename, h, ext=1)
n = sxpar(h, "naxis2")
x = tbget(h, data, "x")
y = tbget(h, data, "y")

>From the looks of things this could easily be accomplished via aliasing 
(or at worst simple wrappers). 

Andy


On Tue, 22 Mar 2005, Perry Greenfield wrote:

> First, I'm heartened to see all the discussion this
> question engendered.
> 
> 1) It's very clear that a functional interface is very
> much desired and needed.
> 
> So we will go ahead and implement a initial version of
> something close to what was proposed quickly. Yes, we'll 
> add a getheadervalue function as well, and try the approach
> of using a keyword flag to add a header return object to
> the getdata function (while keeping the getheader function
> as well). We welcome any further suggestions about what
> would be useful functions.
> 
> 2) There is some disagreement about whether to support
> appending extension numbers to the filename string.
> 
> I'm inclined to be skeptical for the importance of supporting
> this. After all, is:
> 
> getdata("file.fits",3)
> 
> really much more to type than
> 
> getdata("file.fits[3]")?
> 
> (ahem)
>  
> Besides, the former lends itself far more easily to iteration
> (inefficient as it may be to repeatedly open and close the file,
> but that's beside the issue) with variables. I'm inclined to
> put this feature off until I see a more convincing use case
> than familiarity with IRAF or CFITSIO usage). I suppose it 
> may argue for providing a convenience function to parse such
> strings to pull out the useful elements to be used with PyFITS
> but I don't think we need to make this a built in behavior
> of these pyfits functions--yet anyway.
> 
> Perry
> 
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.net
> http://www.scipy.net/mailman/listinfo/astropy
>