raw_input yields trailing carriage return ('\r') when C:\Python27\python.exe is called using the -u option

How to reproduce the error: save the attached file 'input.py' which contains the following lines

-- begin input.py --

i = raw_input("enter y or n: ")
print(repr(i))
print([ord(c) for c in i])

-- end input.py --

then run the two following commands from a windows command shell
python input.py
python -u input.py
and compare the output. (see transcript 1 below)

The same bug affects also the interactive mode: start 'python -u' and enter an arbitrary command. You will get a syntax error at the end of line. (see transcript 2 below)

-- begin transcript 1 of cmd session --

C:\Temp>where python
C:\Python27\python.exe

C:\Temp>python --version
Python 2.7.8

C:\Temp>type input.py

i = raw_input("enter y or n: ")
print(repr(i))
print([ord(c) for c in i])

C:\Temp>python input.py
enter y or n: y
'y'
[121]
-- end transcript 1 of cmd session --

-- begin transcript 2 of cmd session --

C:\Temp>python -u input.py
enter y or n: y
'y\r'
[121, 13]

C:\Temp>python -u
Python 2.7.8 (default, Jun 30 2014, 16:08:48) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print "hello world"
  File "<stdin>", line 1
    print "hello world"
                       ^
SyntaxError: invalid syntax
>>>

-- end transcript 2 of cmd session --

correction: the markers for transcripts 1 and 2 were inserted at the wrong location; here's the correction:

-- begin transcript 1 of cmd session --

C:\Temp>where python
C:\Python27\python.exe

C:\Temp>python --version
Python 2.7.8

C:\Temp>type input.py

i = raw_input("enter y or n: ")
print(repr(i))
print([ord(c) for c in i])

C:\Temp>python input.py
enter y or n: y
'y'
[121]

C:\Temp>python -u input.py
enter y or n: y
'y\r'
[121, 13]

-- end transcript 1 of cmd session --

-- begin transcript 2 of cmd session --

C:\Temp>python -u
Python 2.7.8 (default, Jun 30 2014, 16:08:48) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> print "hello world"
  File "<stdin>", line 1
    print "hello world"
                       ^
SyntaxError: invalid syntax
>>>

-- end transcript 2 of cmd session --

This is the documented behavior of the -u option. It puts the streams in binary mode "on systems where it matters", which would be windows. That is, universal newline processing is disabled when you use -u.

Note that this is no longer an issue in python3: there, -u only affects buffering, and not the binary/text mode (because in python3 there is always a distinction between binary and text mode, regardless of platform).

The bug is not on print, but raw_input().

In Python 3, I worked on the following issues to support fully binary standard streams:

• bpo-10841: "binary stdio"
• bpo-11272: "input() has trailing carriage return on windows", fixed in Python 3.2.1
• bpo-11395: "print(s) fails on Windows with long strings", fixed in Python 3.2.1
• bpo-13119: "Newline for print() is \n on Windows, and not \r\n as expected", will be fixed in Python 3.2.4 and 3.3 (not released yet)

It looks like this issue is the same than bpo-11272: input() removes '\n' but not '\r'.

I backported and adapted most Python 3 fixes related to the Windows binary mode for stdout/stderr used when Python is started with the -u command line option. See attached binary.patch.

My change to file.write() looks wrong because the function returns None and does not loop until all bytes are written.

By the way, string_write() doesn't check if fwrite(n) wrote less than n bytes or failed with an error.

See also the issue bpo-21090 which improves error handling in the file object.

While testing binary.patch, test_subprocess failed because of the issue bpo-19612. I backported the fix:

changeset: 91905:039ac3f01c4e
branch: 2.7
parent: 91895:bffa0b8a16e8
user: Victor Stinner <victor.stinner@gmail.com>
date: Tue Jul 29 00:04:54 2014 +0200
files: Lib/subprocess.py Misc/NEWS
description:
Issue bpo-19612: subprocess.communicate() now also ignores EINVAL when using at
least two pipes.

It's not entirely clear from a quick read whether this was actually fixed or not (probably?), but as 2.7 is out of support it no longer matters :)