[AstroPy] Opening file in PyFits, works in v2.4, not in v3.0.6
Tue Apr 3 12:20:41 CDT 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,
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
More information about the AstroPy