Weird behaviour?

[jussij]

Can someone please explain the following behaviour?

I downloaded and compiled the Python 2.7.2 code base.

I then created this simple c:\temp\test.py macro:

import sys

def main():
print("Please Input 120: ")
input = raw_input()

print("Value Inputed: " + input)

if str(input) == "120":
print("Yes")
else:
print("No")

main()

If I run the macro using the -u (flush buffers) option the if statement always fails:

C:\Temp>python.exe -u c:\temp\test.py
Please Input 120:
120
Value Inputed: 120
No

If I run the macro without the -u option the if statement works as expected:

C:\Temp>python.exe c:\temp\test.py
Please Input 120:
120
Value Inputed: 120
Yes

What's going on?

Cheers Jussi

 

[Chris Angelico]

Can someone please explain the following behaviour?

If I run the macro using the -u (flush buffers) option the if statement always fails:

C:\Temp>python.exe -u c:\temp\test.py
Please Input 120:
120
Value Inputed: 120
No

Here's the essence of your program:

print(repr(raw_input()))

You can use that to verify what's going on. Try running that with and
without the -u option; note, by the way, that -u actually means
"unbuffered", not "flush buffers".

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().

By the way, raw_input() already returns a string. There's no need to
str() it.

ChrisA

 

[Steven D'Aprano]

Can someone please explain the following behaviour?

I downloaded and compiled the Python 2.7.2 code base.

I then created this simple c:\temp\test.py macro:

import sys

def main():
print("Please Input 120: ")
input = raw_input()

print("Value Inputed: " + input)

if str(input) == "120":
print("Yes")
else:
print("No")

main()

If I run the macro using the -u (flush buffers) option the if statement
always fails:

C:\Temp>python.exe -u c:\temp\test.py Please Input 120:
120
Value Inputed: 120
No

I cannot confirm that behaviour. It works fine for me.

Are you sure that the code you show above is *exactly* the code you're
using? Actually, it cannot possibly be the exact code you are using,
since it has been indented. What other changes did you make when retyping
it in your message? Please copy and paste the actual code used, without
retyping or making any modifications.

If the problem still persists, try printing repr(input) and see what it
shows.

Also, a comment on your code: there is no need to call str(input), since
input is already a string. If you replace the test:

str(input) == '120'

with just

input == '120'

does the problem go away? If so, then there's something funny going on
with the call to str(). Please print(str), and see what it shows.

 

[jussij]

so your string actually contains '120\r', as will be revealed
by its repr().

Thanks Chris. That makes sense.

Cheers Jussi

 

[Chris Angelico]

I cannot confirm that behaviour. It works fine for me.

I should mention: Under Linux, there's no \r, so -u or no -u, the
program will work fine.

ChrisA

 

[jussij]

I cannot confirm that behaviour. It works fine for me.

As Chris pointed out there is a \r character at the end of the string and that is causing the if to fail.

I can now see the \r

So this is *Windows only* behaviour.

Cheers Jussi

 

[Steven D'Aprano]

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.

 

[nn]

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.

Maybe it is related to this bug?

http://bugs.python.org/issue11272

 

[jussij]

Maybe it is related to this bug?

http://bugs.python.org/issue11272

I'm running Python 2.7.2 (on Windows) and that version doesn't appear to have that bug:

Python 2.7.2 (default, Apr 23 2013, 11:49:52) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.

"testing"
'testing'

Cheers Jussi

 

[Steven D'Aprano]

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.

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!