Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #44022 > unrolled thread

Weird behaviour?

Back to article view | Back to comp.lang.python

Contents

  Weird behaviour? jussij@zeusedit.com - 2013-04-21 17:37 -0700
    Re: Weird behaviour? Chris Angelico <rosuav@gmail.com> - 2013-04-22 10:56 +1000
      Re: Weird behaviour? jussij@zeusedit.com - 2013-04-21 18:11 -0700
      Re: Weird behaviour? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-22 01:19 +0000
        Re: Weird behaviour? nn <pruebauno@latinmail.com> - 2013-04-22 07:29 -0700
          Re: Weird behaviour? jussij@zeusedit.com - 2013-04-22 16:06 -0700
            Re: Weird behaviour? Chris Angelico <rosuav@gmail.com> - 2013-04-23 10:04 +1000
          Re: Weird behaviour? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-23 00:31 +0000
    Re: Weird behaviour? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-22 01:05 +0000
      Re: Weird behaviour? jussij@zeusedit.com - 2013-04-21 18:14 -0700
      Re: Weird behaviour? Chris Angelico <rosuav@gmail.com> - 2013-04-22 11:13 +1000

#44022 — Weird behaviour?

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

[toc] | [next] | [standalone]

#44023

On Mon, Apr 22, 2013 at 10:37 AM,  <jussij@zeusedit.com> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#44025

On Monday, April 22, 2013 10:56:11 AM UTC+10, Chris Angelico wrote:

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

Thanks Chris. That makes sense.

Cheers Jussi

[toc] | [prev] | [next] | [standalone]

#44027

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

[toc] | [prev] | [next] | [standalone]

#44077

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

[toc] | [prev] | [next] | [standalone]

#44121

On Tuesday, April 23, 2013 12:29:57 AM UTC+10, nn wrote:

> 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.
  >>> print(repr(input()))
  "testing"
  'testing'
  >>>

Cheers Jussi

[toc] | [prev] | [next] | [standalone]

#44125

On Tue, Apr 23, 2013 at 9:06 AM,  <jussij@zeusedit.com> wrote:
> On Tuesday, April 23, 2013 12:29:57 AM UTC+10, nn wrote:
>
>> 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.
>   >>> print(repr(input()))
>   "testing"
>   'testing'
>   >>>

Careful there; go with raw_input() on Py2. And then it does happen.

ChrisA

[toc] | [prev] | [next] | [standalone]

#44127

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

[toc] | [prev] | [next] | [standalone]

#44024

On Sun, 21 Apr 2013 17:37:18 -0700, jussij wrote:

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



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#44026

On Monday, April 22, 2013 11:05:11 AM UTC+10, Steven D'Aprano wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#44028

On Mon, Apr 22, 2013 at 11:05 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web