You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 by reverse_readfile. I would think reverse_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 with os.linesep.
The text was updated successfully, but these errors were encountered:
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: