-
Notifications
You must be signed in to change notification settings - Fork 50
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
Newlines incorrectly handled in reverse_readfile on windows #471
Comments
I'm able to recreate this issue, would fix it today. from monty.io import reverse_readfile
with open("sample_windows.txt", "w", newline="\r\n") as f:
f.write("\r\n".join(["Line1", "Line2", "Line3"]))
with open("sample_unix_mac.txt", "w", newline="\n") as f:
f.write("\n".join(["Line1", "Line2", "Line3"]))
for filename in ("sample_windows.txt", "sample_unix_mac.txt"):
print(f"Reading file: {filename}")
for line in reverse_readfile(filename):
print(repr(line)) Generates:
|
The issue indeed exists for
We now have:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
System
Summary
In reverse_readfile the line separator is hard coded as
\n
, but since monty opens the file in binary mode python doesn't do the usual newline translation you end up with spurious\r
at the end of lines read byreverse_readfile
. I would thinkreverse_readlines
suffers from the same problem. I've came across this only on windows, but a similar issue should happen in macOS, where monty doesn't detect any lines in files, since the line separator is just\r
there.Example code
I don't have a working installation of python+monty on windows, but there's an example output in our CI here.
Suggested solution (if known)
Just guessing, but a simple solution might just be to open the files in text mode or pass the
newline
argument to the underlying python functions, since you.decode('utf8')
all strings anyway. I'm not sure if this would interfere with your handling of compressed files. If it does you'd have to replace every occurrence of\n
in the code withos.linesep
.The text was updated successfully, but these errors were encountered: