Weird behaviour?

[Steven D'Aprano]

On Mon, 22 Apr 2013 07:29:57 -0700, nn wrote:

> On Apr 21, 9:19 pm, Steven D'Aprano <steve
> +comp.lang.pyt... at pearwood.info> wrote:
>> On Mon, 22 Apr 2013 10:56:11 +1000, Chris Angelico wrote:
>> > You're running this under Windows. The convention on Windows is for
>> > end-of-line to be signalled with \r\n, but the convention inside
>> > Python is to use just \n. With the normal use of buffered and parsed
>> > input, this is all handled for you; with unbuffered input, that
>> > translation also seems to be disabled, so your string actually
>> > contains '120\r', as will be revealed by its repr().
>>
>> If that's actually the case, then I would call that a bug in raw_input.
>>
>> Actually, raw_input doesn't seem to cope well with embedded newlines
>> even without the -u option. On Linux, I can embed a control character
>> by typing Ctrl-V followed by Ctrl-<char>. E.g. Ctrl-V Ctrl-M to embed a
>> carriage return, Ctrl-V Ctrl-J to embed a newline. So watch:
>>
>> [steve at ando ~]$ python2.7 -c "x = raw_input('Hello? '); print repr(x)"
>> Hello? 120^M^Jabc
>> '120\r'
>>
>> Everything after the newline is lost.
>>
>> --
>> Steven
> 
> Maybe it is related to this bug?
> 
> http://bugs.python.org/issue11272



I doubt it, I'm not using Windows and that bug is specific to Windows.


Here's the behaviour on Python 3.3:

py> result = input("Type something with control chars: ")
Type something with control chars: something ^T^M else
and a second line
py> print(repr(result))
'something \x14\r else \nand a second line'


Much better!



-- 
Steven