Closed jishnub closed 3 years ago
Thanks for this! I agree, we've been needing a quick one-liner for a while now. Some considerations:
pyfits/astropy.io.fits both have some naming conventions that we can choose to follow. For reading, they use getdata
(and a corresonding getheader
) and for writing they use writeto
and append
. It would be easier for users to transition between libraries if we adopt these, although I don't find the verbage as consistent or accurate as fitsread
and fitswrite
.
Edit: you already had the optional header argument!
Good point about having a name that this easier to guess for users coming from Astropy.
It would be good to have a docstring. Also, export and add these functions to docs/src/api.md
if the idea is to make them "public".
For these functions, too, they should include clear documentation about the awkward dimension permutation that happens in the c/Julia interop. Someone looking for the "how do I read data" as soon as possible probably will trip over the nuance of the column-major arrays.
Yes I was planning to add a docstring, didn't have time for this earlier. About the name - I chose this as matlab uses these names, although they don't match the astropy ones. Personally I find getdata
to be a rather uninformative name if the context isn't clear, although I can use this if there's a consensus.
Should there be an optional parameter to change which HDU is read for multi-extension files? I most often need f[2]
.
Should there be an optional parameter to change which HDU is read for multi-extension files?
It's there already, hduindex
🤦 , sorry.
These convenience functions are useful while working with images. Currently I find this pattern commonly used in my code:
this may be replaced by
and similarly for writing as well. This is easier for REPL usage too.
Not sure if these should be exported (possible conflicts in case users have defined these themselves), so currently it's up to the users to import these.