GH-43374: Fix urlretrieve reporthook to report actual bytes read #142653
Conversation
orsenthil
left a comment
orsenthil
left a comment
There was a problem hiding this comment.
LGTM. This should be back-ported. This is a safe behavior and an improvement.
savannahostrowski
added
3.13
|
Thanks @savannahostrowski for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14. |
pythonGH-142653) (cherry picked from commit 68a01f9) Co-authored-by: Savannah Ostrowski <[email protected]>
|
GH-143588 is a backport of this pull request to the 3.14 branch. |
pythonGH-142653) (cherry picked from commit 68a01f9) Co-authored-by: Savannah Ostrowski <[email protected]>
|
GH-143589 is a backport of this pull request to the 3.13 branch. |
|
There is a call to reporthook just a few lines above before reading the first block. Would it not weird? |
|
Also the docs say
I am not sure that passing the kength of the block that was just read is the 'block size' in this case. Or maybe we should documenty it better. We should also document for blocknum == 0 that we first give the blocksize. |
4 participants
Spelunking through bugs marked with EOL version labels... The docs aren't explicit about what the second argument should represent. The current behavior (always reporting block size 8192) makes progress tracking unreliable since the last block could be smaller. This change makes reporthook report actual bytes read, which is more useful.