-
Notifications
You must be signed in to change notification settings - Fork 51
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
Preserve line separator format (Unix vs. Windows) #121
Comments
Or maybe we should modernise them all to Unix style ;-) We'll need to look at 2to3 and see how much code we'd need to duplicate in order to fix this ourselves. If it doesn't require duplicating too much, it should be OK. |
For now, you can set your .gitattributes file appropriately so that it ignores line ending type changes and always commits them as unix line separators. |
Most likely that 2to3 need to be opened in binary mode for writing. https://github.com/python/cpython/blob/master/Lib/lib2to3/refactor.py#L527 (write_file) |
The implementation is different depending on whether python-modernize is running on Python 2 or 3: https://github.com/python/cpython/blob/master/Lib/lib2to3/refactor.py#L113 . On Python 2 at least, setting The Right Thing is to preserve the line-ending style of each file, but that looks significantly more difficult to do, unless we detect the line-ending style ourselves and set |
@daira why not just read input file as binary? You will get the strings, but without any newline transformations. |
So, it looks like subclassing of |
2to3 already opens the file as binary, but it normalises the line endings to Unix style before processing the code, and then converts to platform native when writing it again. That presumably means that Windows style line endings can't be passed through 2to3's machinery, or 2to3 wouldn't bother normalising them. We'd have to subclass RefactoringTool, duplicate |
It is easy to do once, but not every single time. So, how about hack to read the linefeed stats when "-w" is supplied and rewrite of the file after processing? |
That's what scripting is for. |
As I pointed out, setting [Edit: the monkey-patch below is probably better, if it works.] |
It's easy to do, but too much code? Everyone should script it, but doing it right once from the beginning is not worth it? :( |
I think this should work (untested):
|
Hmm, not sure that will do the right thing on Windows for lines created by a fixer, though. |
I suspect that 2to3's parser expects Unix style newlines, otherwise it wouldn't bother normalising them in the first place. That could be a red herring, though. |
I used the os.linesep approach for the pull request. I believe this should also work on Python 3 based on the API docs; we'll see what Travis says. |
Nope, setting |
I had another idea. Fixed now -- please review. |
https://github.com/python/cpython/blob/master/Lib/lib2to3/refactor.py#L540 explicitly converts file to system-specific newlines without any option to turn this off! What is the ill logic behind that? |
Signed-off-by: Daira Hopwood <[email protected]>
I think we should use something like the auto-detection method in @techtonik's patch, rather than the |
@daira you can take my patch and work on top of it. |
Actually it looks as though I won't have time to do this before I go on holiday on Thursday (until the 28th November). So someone else should probably look at it. |
I tried running python-modernize on Windows on source files that use Unix line separators. This changed them over to Windows line separators. That's not very helpful. A diff now shows every single line as changed. The previous line separator format should be preserved.
The text was updated successfully, but these errors were encountered: