[AstroPy] Opening file in PyFits, works in v2.4, not in v3.0.6

Erik Bray embray at stsci.edu
Tue Apr 3 13:20:41 EDT 2012

On 04/03/2012 12:07 PM, Wolfgang Kerzendorf wrote:
> Hey guys,
> I would have it the other way round: Always raises an exception - except when specifically asked not to, then it will just warn.
> I think the algorithms in fitsverify are there to ensure the integrity of the data. If it doesn't comply - the integrity of the data can not be guaranteed (in this case, the integrity is fine, it's just a bad implementation of the fits standard on the telescopes end afaict). Other data formats do similar things: zip files do not decompress if the CRC doesn't match.
> My 2 cents,
>     Wolfgang

Part of me agrees with this in principle, but in practice it just 
wouldn't work.  It's like how part of me wishes that whenever a web 
browser hits some malformed or invalid HTML it would just throw up an 
error and refuse to render the page.

But it's a good thing that web browsers *don't* do that, as such 
behavior would have severely hindered the adoption and growth of the 
web.  I think that FITS, for better or for worse, needs to be treated a 
little like HTML in that respect.

In particular, it shouldn't throw up errors when it's fairly unambiguous 
what was *meant*.  There's absolutely nothing about the "spaces for 
padding" requirement that affects parsing of the header--as long as the 
header ends on the right alignment that's all that matters.

I already have a fix in git (and subversion as soon as a I `git svn 
dcommit`) for this issue.  So I'll try to slip that in to the 3.0.7 
release, which I hope to get done today or tomorrow.

Incidentally, PyFITS has no problem with the invalid apostrophe in the 
origin keyword.  Maybe it should say something about that and consider 
fixing it...


More information about the AstroPy mailing list