KEMBAR78
gh-122179: Fix hashlib.file_digest and non-blocking I/O by srittau · Pull Request #122183 · python/cpython · GitHub
Skip to content

Conversation

@srittau
Copy link
Contributor

@srittau srittau commented Jul 23, 2024

@srittau
Copy link
Contributor Author

srittau commented Jul 23, 2024

While this is technically an API change, I think this should be backported to releases that are still in bugfix mode, as the current behavior can cause hard to find bugs instead of failing fast.

Copy link
Contributor

@cmaloney cmaloney left a comment

Choose a reason for hiding this comment

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

I think this is a positive change as is and test covers if this regresses in the future.

I think part of the cause of this is RawIO (ex. FileIO) vs. BufferedIO (and TextIO). Code exists in the wild using RawIO with this, which returns None, so updating to be more batteries included makes sense.

@picnixz picnixz self-requested a review April 14, 2025 09:51
Copy link
Member

@picnixz picnixz left a comment

Choose a reason for hiding this comment

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

I reviewed this last year, before I knew more about the workflow so here are some improved comments.

@gpshead gpshead added the needs backport to 3.13 bugs and security fixes label Apr 21, 2025
@gpshead gpshead merged commit 2b47f46 into python:main Apr 21, 2025
45 checks passed
@miss-islington-app
Copy link

Thanks @srittau for the PR, and @gpshead for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

@miss-islington-app
Copy link

Sorry, @srittau and @gpshead, I could not cleanly backport this to 3.13 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 2b47f46d7dc30d27b2486991fea4acd83553294b 3.13

gpshead added a commit that referenced this pull request Apr 21, 2025
…2787)

gh-122179: Fix hashlib.file_digest and non-blocking I/O (GH-122183)

* Fix hashlib.file_digest and non-blocking I/O
* Add documentation around this behavior
* Add versionchanged

(cherry picked from commit 2b47f46)

Co-authored-by: Sebastian Rittau <srittau@rittau.biz>
@srittau srittau deleted the file-digest-readinto branch April 21, 2025 22:35
@hugovk hugovk removed the needs backport to 3.13 bugs and security fixes label May 20, 2025
.. versionadded:: 3.11

.. versionchanged:: next
Now raises a :exc:`BlockingIOError` if the file is opened in blocking
Copy link
Contributor

Choose a reason for hiding this comment

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

Was this meant to be "BlockingIOError if the file is not opened in blocking mode" or "BlockingIOError if the file is opened in non-blocking mode."?

As written it contradicts the previous addition 30 lines up and the NEWS.d entry.

Copy link
Contributor

@cmaloney cmaloney Oct 2, 2025

Choose a reason for hiding this comment

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

Should be "if the file is opened in non-blocking mode."

More specifically:
If .readinto returns None because it has no data and would block raises BlockingIOError.

(PR to update the docs welcome if you're interested in contributing directly; happy to help review)

Copy link
Contributor

Choose a reason for hiding this comment

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

will do

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants