You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is always at least one extension in a FITS file, so I think this is the right behavior. Maybe we could add a method that does something like len(fits) == 1 and not fits[0].has_data() to indicate no data other than header entries are present
There is always at least one extension in a FITS file
A FITS file, yes, but the second code example shows that this is not true for a FITS object. Creating a FITS object and not doing anything to it does initially result in something that has no HDUs.
I suppose it goes back to the question of whether or not a FITS object corresponds a valid FITS file on disk (#323).
But in any case, I would argue that calling len() should never modify an object, or start writing things to disk.
I think the bug here is that fits[-1] doesn't work.
The reason len creates the hdu list is because FITS files can have thousands of extensions, so this is done lazily. It may be there is a better way, but do note that it is not possible to determine the number of extensions without running through the whole file, which can be expensive.
Calling
len()
on an empty (i.e. newly created) FITS adds a HDU:The
len()
call indeed creates the HDU:This makes the intuitive (well, to me) check
len(fits) == 0
for a newly created FITS unusable.The text was updated successfully, but these errors were encountered: