Skip to content

Fix progress tracking for multibyte text files - #856

Open
RamiNoodle733 wants to merge 2 commits into
simonw:mainfrom
RamiNoodle733:knightwatch-fix-utf16-progress-439
Open

Fix progress tracking for multibyte text files#856
RamiNoodle733 wants to merge 2 commits into
simonw:mainfrom
RamiNoodle733:knightwatch-fix-utf16-progress-439

Conversation

@RamiNoodle733

@RamiNoodle733 RamiNoodle733 commented Sep 12, 2026

Copy link
Copy Markdown
Contributor

Fixes #439.

The progress bar currently uses the file size in bytes as its total, but UpdateWrapper advances it using len() on decoded text. That makes UTF-16 input finish near 50% and can also miscount other multibyte encodings.

This changes UpdateWrapper to advance from the wrapped stream's tell() position. Iteration uses readline() so TextIOWrapper.tell() remains available and reports the logical position in the underlying byte stream. Non-seekable streams retain the previous len() fallback.

Regression coverage checks UTF-8, UTF-16-LE, UTF-32-LE, CRLF translation, and the read() path.

Validation performed locally with a focused Python reproducer for those byte-count cases. The full repository test suite was not run because this runtime could not resolve github.com for a checkout.


📚 Documentation preview 📚: https://sqlite-utils--856.org.readthedocs.build/en/856/

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.

Misleading progress bar against utf-16-le CSV input

1 participant