Skip to content

Clarify file signature detection details in astropy.utils.data.get_readable_fileobj() - #12641

Merged
pllim merged 1 commit into
astropy:mainfrom
eerovaher:fileobj-bufferedreader
Oct 27, 2022
Merged

pllim merged 1 commit into
astropy:mainfrom
eerovaher:fileobj-bufferedreader

Conversation

@eerovaher

@eerovaher eerovaher commented Dec 27, 2021 •

Copy link
Copy Markdown
Member

Description

Currently astropy.utils.data.get_readable_fileobj() checks the file signature of a non-random access file-like object (i.e. one that does not have a seek() method) by reading in all its contents to access the first few bytes. It would be better to wrap such a file-like object in a io.BufferedReader. A comment in the code lists a few Python 2 reasons why that can't be done, but Python 2 is no longer supported so those reasons are not valid anymore.

EDIT: The discussion below came to the conclusion that compatibility issues are still relevant despite Python 2 not being supported anymore, so this pull request only updates the code comment so that it wouldn't be misleading.

Checklist for package maintainer(s)

This checklist is meant to remind the package maintainer(s) who will review this pull request of some common things to look for. This list is not exhaustive.

  • 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.
  • 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 a milestone set? Milestone must be set but astropy-bot check might be missing; 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.

@pllim

This comment has been minimized.

@pllim

pllim commented Dec 27, 2021

Copy link
Copy Markdown
Member

Okay, I take it back. I see this failure in another PR too. Something must have just changed upstream...

@eerovaher

This comment has been minimized.

@eerovaher

This comment has been minimized.

@pllim

pllim commented Dec 27, 2021

Copy link
Copy Markdown
Member

Might have to just pin it (#12643) until we can figure out astropy/pytest-astropy-header#41

@eerovaher
eerovaher force-pushed the fileobj-bufferedreader branch from cc96af0 to 016381a Compare December 27, 2021 22:42
@pllim
pllim requested review from embray and saimn December 28, 2021 21:36
@eerovaher eerovaher mentioned this pull request Jan 21, 2022
8 of 9 tasks
@pllim

pllim commented Apr 21, 2022

Copy link
Copy Markdown
Member

@saimn , do you want to have a look by feature freeze or should we move the milestone?

@saimn saimn modified the milestones: v5.1, v5.2 Apr 22, 2022
@saimn

saimn commented Apr 22, 2022

Copy link
Copy Markdown
Contributor

Sorry @eerovaher it's too short to do a proper review before the freeze, especially since there was a previous attempt at doing a similar change (#7981). I don't remember all the details but the gain of doing this change was not clear at that time (and the code change in #7981 was a bit more complicated).

@github-actions github-actions Bot added the Close? Tell stale bot that this issue/PR is stale label May 27, 2022
@github-actions

Copy link
Copy Markdown
Contributor

Hi humans 👋 - this pull request hasn't had any new commits for approximately 4 months. I plan to close this in 30 days if the pull request doesn't have any new commits by then.

In lieu of a stalled pull request, please consider closing this and open an issue instead if a reminder is needed to revisit in the future. Maintainers may also choose to add keep-open label to keep this PR open but it is discouraged unless absolutely necessary.

If this PR still needs to be reviewed, as an author, you can rebase it to reset the clock.

If you believe I commented on this pull request incorrectly, please report this here.

@github-actions

Copy link
Copy Markdown
Contributor

I'm going to close this pull request as per my previous message. If you think what is being added/fixed here is still important, please remember to open an issue to keep track of it. Thanks!

If this is the first time I am commenting on this issue, or if you believe I closed this issue incorrectly, please report this here.

@github-actions github-actions Bot added the closed-by-bot Closed by stale bot label Jun 27, 2022
@github-actions github-actions Bot closed this Jun 27, 2022
@pllim

pllim commented Jun 27, 2022

Copy link
Copy Markdown
Member

Oooops I think this fell through the cracks. @eerovaher , if you are still interested, we can re-open but you will have to rebase and force push to reset the stale clock. Please let me know. I apologize for any inconvenience caused.

@eerovaher eerovaher removed Close? Tell stale bot that this issue/PR is stale closed-by-bot Closed by stale bot labels Jun 27, 2022
@eerovaher eerovaher reopened this Jun 27, 2022
@eerovaher
eerovaher force-pushed the fileobj-bufferedreader branch from 016381a to 46d42ee Compare June 27, 2022 21:11
@eerovaher

Copy link
Copy Markdown
Member Author

The comments seem to indicate that the code that would be replaced is overly complicated because of backwards compatibility with Python 2, and the fact that this pull request passes CI tests confirms it. I think it would be good to merge this, so I have reopened the pull request and rebased the commits.

@pllim

pllim commented Jun 28, 2022

Copy link
Copy Markdown
Member

Thanks!

@pllim

pllim commented Jun 29, 2022

Copy link
Copy Markdown
Member

I don't see anything obviously wrong with the diff but I restarted the dev job to make sure it matches the failures on main. If not, they might be related to your change here. I will also kick off the cron jobs, just in case.

@pllim pllim added the Extra CI Run cron CI as part of PR label Jun 29, 2022
@pllim

pllim commented Jun 29, 2022

Copy link
Copy Markdown
Member

I don't think the dev job failures are related.

Comment thread astropy/utils/data.py Outdated
fileobj.seek(0)
else:
fileobj = io.BufferedReader(fileobj)
signature = fileobj.peek(4)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

But if a file-like object has no .seek method, it will also most probably not have a .seekable method and this will crash ?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

If an object does not have seek() and seekable() methods then it is not an instance of io.IOBase.

Comment thread astropy/utils/tests/test_data.py Outdated
raise OSError

def seekable(self):
return False

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

The test seems quite different from the initial one, which was a simple object with just a read method. What's the goal here ?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

The goal of the changes here was to ensure that FakeStream would be a subclass of io.RawIOBase.

@saimn

saimn commented Jun 29, 2022

Copy link
Copy Markdown
Contributor

Is there a specific use case for this change ? While looking at this in the past it wasn't clear if any change was needed/useful.

@eerovaher

Copy link
Copy Markdown
Member Author

For me the main motivation for this pull request was to remove Python 2 compatibility code, and the updated code always works as long as the file object is an instance of io.RawIOBase, which I believe is a reasonable assumption. If we do wish to support file objects that are not instances of io.RawIOBase then the code should not be updated, but the comments should be so that they would describe the real reason why the code is the way it is.

@pllim

pllim commented Oct 20, 2022

Copy link
Copy Markdown
Member

@eerovaher , do you want to do one more rebase to get clean CI?

@aarchiba , are you interested to take a look since you refactored a bunch of this before?

@eerovaher
eerovaher force-pushed the fileobj-bufferedreader branch from 46d42ee to 0184b77 Compare October 21, 2022 16:35
@pllim

pllim commented Oct 21, 2022

Copy link
Copy Markdown
Member

WCSAxes failures are unrelated.

@pllim

pllim commented Oct 26, 2022

Copy link
Copy Markdown
Member

@saimn was going to have another look. Thanks!

@saimn

saimn commented Oct 26, 2022

Copy link
Copy Markdown
Contributor

If we do wish to support file objects that are not instances of io.RawIOBase then the code should not be updated, but the comments should be so that they would describe the real reason why the code is the way it is.

Right, the code and the test make it clear that the goal is support objects that are not io.IOBase instances and only have a read method. I don't know what are those objects (the other comment mention py.path.LocalPath but not sure if this is still true), but I think we need to keep this feature. So indeed we can probably just remove the Python 2 mention in the comment, and keep the comment about BufferedReader so that if some day we have a performance issue with such an object we will know what to do.

Previously a code comment explained Python 2 compatibility requirements.
However, in astropyGH-12641 it was decided that even though Python 2 is no
longer supported, compatibility concerns are still relevant . [ci skip]
@eerovaher
eerovaher force-pushed the fileobj-bufferedreader branch from 0184b77 to 5065ed0 Compare October 26, 2022 22:33
@eerovaher eerovaher changed the title Improve file signature detection in astropy.utils.data.get_readable_fileobj() Clarify file signature detection details in astropy.utils.data.get_readable_fileobj() Oct 26, 2022
@eerovaher eerovaher removed Refactoring Extra CI Run cron CI as part of PR labels Oct 26, 2022

@pllim pllim left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

LGTM now. Thanks!

@pllim
pllim merged commit 82d3799 into astropy:main Oct 27, 2022
@eerovaher
eerovaher deleted the fileobj-bufferedreader branch October 27, 2022 12:19
dhomeier pushed a commit to dhomeier/astropy that referenced this pull request Oct 28, 2022
Previously a code comment explained Python 2 compatibility requirements.
However, in astropyGH-12641 it was decided that even though Python 2 is no
longer supported, compatibility concerns are still relevant . [ci skip]
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.

3 participants