Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix missing .shape check for array data #14528

Merged
merged 1 commit into from Mar 15, 2023
Merged

Conversation

kYwzor
Copy link
Member

@kYwzor kYwzor commented Mar 14, 2023

Description

This pull request is to address ImageHDU missing a necessary check for zero-dimensional data.

Fixes #14527

@kYwzor kYwzor requested a review from saimn as a code owner March 14, 2023 16:42
@github-actions
Copy link

github-actions bot commented Mar 14, 2023

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

  • Do the proposed changes actually accomplish desired goals?
  • Do the proposed changes follow the Astropy coding guidelines?
  • Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
  • Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
  • Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see "When to rebase and squash commits".
  • Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
  • Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
  • Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
  • Is a milestone set? Milestone must be set but we cannot check for it on Actions; do not let the green checkmark fool you.
  • At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

@kYwzor
Copy link
Member Author

kYwzor commented Mar 14, 2023

Very interesting that test_new_hdulist_extend_keyword is failing:

def test_new_hdulist_extend_keyword(self):
"""Regression test for https://aeon.stsci.edu/ssb/trac/pyfits/ticket/114
Tests that adding a PrimaryHDU to a new HDUList object updates the
EXTEND keyword on that HDU.
"""
h0 = fits.Header()
hdu = fits.PrimaryHDU(header=h0)
sci = fits.ImageHDU(data=np.array(10))
image = fits.HDUList([hdu, sci])
image.writeto(self.temp("temp.fits"))
assert "EXTEND" in hdu.header
assert hdu.header["EXTEND"] is True

I can no longer access the referenced issue, but apparently this is just supposed to test if the EXTEND keyword is added to the header. However there's two weird things about it:

  • This is actually silently creating a corrupt FITS file, but since it is not read back it never detected the issue (basically what this PR is trying to fix)
  • I don't understand why the HDUList is being written to a file at all, since the assertion would pass as soon as the HDUList is created, and the file isn't being read back anyway.

I will change this test to fix this (unless I'm missing something?).

with pytest.raises(TypeError, match=msg):
fits.ImageHDU(data=np.array(1))
with pytest.raises(TypeError, match=msg):
fits.PrimaryHDU(data=np.array(1))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, weird that this test_image.py is not being ignored by coverage. @nstarman , is this setting being ignored? You moved it in #13266 .

"*/astropy/*/tests/*",

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For some reason it complains about coverage on test files while the rest of the tests are still running, but as soon as everything finishes it stops complaining. This also happened to my commit last week, but I have no clue why.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is because we have several jobs in the same build that upload coverage reports. They don't all check the same test suite. The most comprehensive one is also the slowest, so when that one is done is when you should have a look. I won't worry about the complains while the test suite is still running. 😸

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm. This is what the coverage docs say:

Coverage.py will read from “pyproject.toml” if TOML support is available, either because you are running on Python 3.11 or later, or because you installed with the toml extra (pip install coverage[toml]). Configuration must be within the [tool.coverage] section, for example, [tool.coverage.run].

AFAIK it should be working. I see coverage[toml] in setup[cfg].

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think we need a ** instead of a *? Or maybe a */* since this is one more level down?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, maybe **.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

codecov was happy when the change was made in #13266, so maybe those files were already not ignored before that and we would need **. To be checked with another PR ?

@pllim pllim added this to the v5.0.6 milestone Mar 14, 2023
@pllim pllim added the Bug label Mar 14, 2023
@pllim pllim modified the milestones: v5.0.6, v5.3 Mar 14, 2023
@pllim
Copy link
Member

pllim commented Mar 14, 2023

test_new_hdulist_extend_keyword was moved from PyFITS over 11 years ago. Unless @embray remembers, I don't think anyone knows the original intent anymore. We no longer have access to the Trac tickets.

try:
data = np.array(data)
except Exception:
raise TypeError(
Copy link
Member Author

@kYwzor kYwzor Mar 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coverage is complaining about this TypeError, even though I did not add it. That said it is right in the sense that this TypeError is indeed never checked in any test.
More importantly: I can't think of any scenario where "data = np.array(data)" would actually raise an exception. Numpy seems to happily eat anything you throw at it, and if it is not array_like it will just create a 0-dimensional array containing the object. So I believe this part of the code is actually not needed. I will remove it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case, you may use # pragma: no cover to ask coverage to stop complaining. The check goes through diff even though you might not have really touched that code.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I would rather delete the try-except, assuming there's no way it will trigger (I don't think it should be possible, looking over at the documentation).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That should be a separate PR, if you really want to pursue, as it is out of scope here.

Copy link
Member Author

@kYwzor kYwzor Mar 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in the latest commit, this PR should be ready now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

np.array([[1,2],[2,3,4]]) raises an exception, so let's just keep code as it is :)
And covering all exceptions is not easy, not done most of the time, and not in the scope of this PR, so I don't mind if Coverage is complaining.

@pllim
Copy link
Member

pllim commented Mar 14, 2023

Might need to squash but maybe we should wait for saimn first. Thanks!

@saimn
Copy link
Contributor

saimn commented Mar 14, 2023

Thanks for the PR, changes make sense, I forgot about Numpy scalars when doing #10041.

@pllim
Copy link
Member

pllim commented Mar 14, 2023

Thanks, @saimn ! @kYwzor , can you please squash the commits into one?

@kYwzor
Copy link
Member Author

kYwzor commented Mar 15, 2023

Commits are squashed.

Copy link
Member

@pllim pllim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM but @saimn should look again and decide if we want to backport or not. I tentatively said we don't have to backport.

Thanks, all!

Copy link
Contributor

@saimn saimn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @kYwzor.

@saimn saimn merged commit 5408748 into astropy:main Mar 15, 2023
@saimn
Copy link
Contributor

saimn commented Mar 15, 2023

v5.3 is fine I think, it's really an edge case so backport doesn't seem needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

io.fits creates a corrupt FITS files if a ImageHDU contains zero-dimensional data
4 participants