What type of line breaks does a Python script normally have?

My boss keeps getting annoyed at me for having Windows line breaks in my Python scripts, but I can't for the life of me work out how they are causing him a problem.

Is '\r\n' the normal line-break for a Python script? Or does that only happen on IDLE for PC?

PS: OK, it seems when I write the script on a Mac that it has '\n's, but is there any way that '\r\n' will cause a problem?

Edit: OK... now I'm totally confused. When I interpret files written in Windows in Pyth开发者_如何学Con they all spit out when I print lines to the screen as '\n'. Does the Python interpreter for Windows translate line-breaks?

This has nothing to do with Python but with the underlying OS. If you save a text file on Windows, you get CRLF linebreaks, if you save it on Mac/Unix systems, you get LF linebreaks (and on stone-age Macs, CR linebreaks).

Use an editor that allows you to preserve the line break format of your files. No, Notepad doesn't, but most editors I've seen do. UltraEdit and EditPadPro are the ones I know, and I can recommend both. I'm pretty sure that IDEs like PyDev/Eclipse will handle that too, but I haven't tried.

Make a Python script which replaces '\r\n' with '\n'

An run it every time you give the code to your boss.

:)

I've had the same problem. Yes, doing a simple find-and-replace should fix this problem. However you'll have to do it every time you share code; you might want to think about automating it somehow. I never did do that myself.

This sed one-liner will convert the Python script to have the desired line endings:

sed 's/\r\n/\n/g' <windows_script >unix_script

newlines (\n), as opposed to carriage-return/linefeeds (\n\r), are pretty much the canonical line ending everywhere, except for dedicated Windows-only enclaves.

You shouldn't really be repeatedly manually converting line endings. That's not really a "Good Thing" Ⓡ.

To support this, git has the core.autocrlf option. When enabled on Windows systems, files with standard newline endings will be converted to CRLF when checked out, and converted back on the way back in.

This seems to be a seamless way to cope with the problem of Windows line-endings when running GUI editors and IDEs on Windows. Your editor is probably expecting CRLF line endings on Windows and will get them when using git with this option, which I believe is set to true by default on Windows installs.

If you're not using Git, maybe it's time you did? Even when working alone it has lots of value. You can version your own code for backing up and providing alternates.

Some users will be using GitBash / Cygwin / Ming tools on Windows, possibly with GitBash supplied vim, and will not appreciate CRLF line-endings. Those users can turn the Git core.autocrlf setting off (false) before cloning a repo to avoid inappropriate "corrections", and thereby see proper newline-only line endings when editing files, even on Windows. This may also help when using other Linux tools when running on Windows that also expect newline line endings.

Git has three levels of settings: "system" (probably set in C:\Program Files\...), "global" (set in your home directory Git config file and affecting all your repos) and "local" set in each repo's .git/config file. Latter levels override the former levels, which can be helpful if your organisation has locked down your C drive.

Here are some of the Git commands to query and update your settings (and you can just edit the configuration files themselves as well):

• git config --list --show-origin: Lists all your settings and the file locations where they are set. A setting may be repeated so the lower level will override the higher.
• git config --get core.autocrlf: Get the effective setting from the combination of settings you currently have in place.
• git config --system core.autocrlf false: Switch off automatic conversion at the system level, for all repos.
• git config --global core.autocrlf false: Switch off automatic conversion in all repos from your home directory config file.

Remember, set core.autocrlf to what you need before you clone. Reference here: https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings