On Windows, spurious ^M characters are added to Unix formatted files

[rasa]

Our team uses a .gitattributes file of

* -text  

This means files checked out on Windows will often contain only Unix line endings: just ^Js (LF), and no ^Ms (CRs).

But when these files are reformatted using pydocstringformatter, the modified lines now end in ^M^J, but only those lines.

Perhaps pydocstringformatter can sense the line ending characters of the lines it's modifying, and use them instead of introducing ^Ms where none were there previously?

I think this a better solution than adding a config option, but a config option would be nice too, to be explicit.

If there's interest, I can try to cobble a PR, that accomplishes this task.

[DanielNoord]

I'd certainly be interested in a PR and this probably shouldn't be a config. A little googling shows that it is actually expected behaviour of Python to read CRLF to LF but then output CRLF when writing again, although I think this is only in binary mode. We're breaking that assumption apparently, so let's fix that!

We could add an option to make this a toggleable 'fix', but I think that's probably better dealt with by an other tool.

I'm not sure what the best approach is, but looking at https://peps.python.org/pep-0278/, https://discuss.python.org/t/will-open-function-change-line-endings-in-files/7150/5 and other things I quickly found it seems like opening in binary mode might be the best solution as we then rely on Python's own correct handling of this issue!

[rasa]

Ok, I will start working on this now. PEP 278 says it offers "universal newline" support, but only on reads. Perhaps we open the file for reading first, read the entire file, and then use the newline characters returned in the newlines attribute when we output the file (or reopen the file for writing if --write was specified)?

[DanielNoord]

https://discuss.python.org/t/will-open-function-change-line-endings-in-files/7150/6 says that writing should fix this as well. But we probably need to double check that.