In Python 3.2, the builtin function input() returns a string with a trailing '\r' on windows:

    C:\Python32>python
    Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> print(repr(input()))
    test
    'test\r'
    >>>

This breaks code that expects the string to be stripped, e.g. 'pydoc.py -b' doesn't recognise its commands:

C:\Python32>python lib\pydoc.py -b
Server ready at http://localhost:4680/
Server commands: [b]rowser, [q]uit
server> q
Server commands: [b]rowser, [q]uit
server> b
Server commands: [b]rowser, [q]uit
server>

Confirmed on Python 3.2 (winxp). The problem doesn't seem to exist on 3.1.3.

On WinXp with Python 3.2a4+ or 3.1.3 I cannot reproduce this issue.

With py3.2 final, I can reproduce this bug with command line (as demonstrated by the OP) but not with the IDLE (for 3.2a4+ I have only command line, which I compiled myself).

bpo-10841 may be related.

Confirmed on Python 3.2 (winxp).
The problem doesn't seem to exist on 3.1.3.

Can you try Python 3.1 with -u command line flag?

I changed Python 3.2 to always open all files in binary module, not only if -u flag is used. I had also to fix the parser to support \r\n newlines: it looks like I missed something in the parser.

Can you try Python 3.1 with -u command line flag?
Yes, I can reproduce it with 3.1.3 with -u flag

Yes, it does indeed look like stdin has been opened in binary mode. Just iterating over it also gives the spurious carriage returns:

    C:\Python32>python
    Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import sys
    >>> for line in sys.stdin:
    ...     print(repr(line))
    ...
    hello
    'hello\r\n'
    ^Z
    >>>

Here is a patch to fix input() on Windows: strip also \r.

Is it possible to add some tests for input()?

Also the patch uses tabs instead of spaces.

C:\Python32>python
    Python 3.2 ... on win32
    >>> import sys
    >>> for line in sys.stdin:
    ...     print(repr(line))
    ...
    hello
    'hello\r\n'
    ^Z

Oh yes, I confirm that there is a second bug: sys.stdin doesn't translate \r\n to \n, whereas sys.stdin is a text file.

Attached patch fixes both issues.

Is it possible to add some tests for input()?

input() has already tests, but the bug was not detected because the test uses a mockup, not a subprocess. Moreover, I don't think that it is possible to test input() for the TTY case. It is not easy to test a TTY, especially on Windows.

If anyone knows how to reproduce the two bugs with a short Python script, I can try to convert it into a test.

Also the patch uses tabs instead of spaces.

Yeah, I hate producing patches on Windows. Fixed in the new patch (prepared on Linux).

If anyone knows how to reproduce the two bugs with a short Python
script, I can try to convert it into a test.

If you don't mind kicking off some sub-processes then here's a script that shows the bugs.

I couldn't figure out how to do a script that would work on Python 3.1 but fail on Python 3.2, because I think to show the problem you have to use the shell to pipe data and Popen on Python 3.1 quotes the pipe character.

Fixed in 3.3 (r88530) and 3.2 (r88531). Others versions are not affected.

Thanks Duncan Booth, I added tests based on your stdintests.py script. I used directly stdin argument of Popen() instead of using cmd.exe to create the pipe (which is not portable).

On my pc with both architecture (x86 and x64) the bug is still presentes

On my pc with both architecture (x86 and x64) the bug
is still presentes

Which version of Python are you using? Python 3.1, Python 3.2.1 and Python 3.3 doesn't have the bug, Python 3.2.0 has the bug. Python 3.2.1 doesn't have the bug, but it's not released yet: it will be released in a few weeks. Python 3.3 is a development version.

I'm using the 3.2,
the 3.0 has the bug?

2011/5/25 STINNER Victor <report@bugs.python.org>

STINNER Victor <victor.stinner@haypocalc.com> added the comment:

> On my pc with both architecture (x86 and x64) the bug
> is still presentes

Which version of Python are you using? Python 3.1, Python 3.2.1 and Python
3.3 doesn't have the bug, Python 3.2.0 has the bug. Python 3.2.1 doesn't
have the bug, but it's not released yet: it will be released in a few weeks.
Python 3.3 is a development version.

----------

---

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue11272\>

---

You are using the only version that has the bug (3.2.0, also called 3.2). The fixed version will be released shortly (3.2.1).