On Mon, 22 Apr 2013 07:29:57 -0700, nn wrote:
> On Apr 21, 9:19 pm, Steven D'Aprano <steve
> +comp.lang.pyt...@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@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
--
http://mail.python.org/mailman/listinfo/python-list
