Windows Python 2.4: Unbuffered flag causes SyntaxError on interactive sessions?

[Lonnie Princehouse]

>From the cmd shell on both Windows 2k and XP, I'm getting this weird
syntax error in conjunction with the unbuffered flag. It works fine
without -u. Has anyone else encountered it? This didn't happen with
Python 2.2...

C:\>python -u
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.

print 'hello'

File "<stdin>", line 1
print 'hello'
^
SyntaxError: invalid syntax
(sorry if this is a known/fixed bug... I couldn't find anything about
it)

[Michael Hoffman]

Lonnie Princehouse wrote:

C:\>python -u
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.

print 'hello'
File "<stdin>", line 1
print 'hello'
^
SyntaxError: invalid syntax

Worksforme:

C:\Python24>python.exe -u
Python 2.4.1 (#65, May 24 2005, 13:43:04) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.

print 'hello'

hello

Strange that your python build is from 30 March and mine is from 24 May.
--
Michael Hoffman

[Irmen de Jong]

Michael Hoffman wrote:

Lonnie Princehouse wrote:

C:\>python -u
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.

> print 'hello'

File "<stdin>", line 1
print 'hello'
^
SyntaxError: invalid syntax

Worksforme:

C:\Python24>python.exe -u
Python 2.4.1 (#65, May 24 2005, 13:43:04) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.

>>> print 'hello'

hello

Strange that your python build is from 30 March and mine is from 24 May.

Problem also occurs on my machine using Win XP Home,
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32
even just typing "print" at the interactive prompt causes a syntax error...

--Irmen

[Lonnie Princehouse]

Weird. Did you build Python yourself? The 2.4.1 release on python.org
is from March 30.
I just tried ActiveState's 2.4.1... the same thing happens.

[Michael Hoffman]

Lonnie Princehouse wrote:

Weird. Did you build Python yourself?

No.
--
Michael Hoffman

[Terry Reedy]

"Lonnie Princehouse" <fi**************@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...

Weird. Did you build Python yourself? The 2.4.1 release on python.org
is from March 30.
I just tried ActiveState's 2.4.1... the same thing happens.

Please report this on the SourceForge bug list, including the details of
the two releases and de Jong's confirmation (and even Hoffman's
non-confirmation). The 2.4.2 release process starts soon and it would be
nice to have this fixed.

Terry J. Reedy

[Lonnie Princehouse]

Will do

[Reinhold Birkenfeld]

Irmen de Jong wrote:

Michael Hoffman wrote:

Lonnie Princehouse wrote:

C:\>python -u
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)]
on win32
Type "help", "copyright", "credits" or "license" for more information.

>> print 'hello'
File "<stdin>", line 1
print 'hello'
^
SyntaxError: invalid syntax

Worksforme:

C:\Python24>python.exe -u
Python 2.4.1 (#65, May 24 2005, 13:43:04) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.

>>> print 'hello'

hello

Strange that your python build is from 30 March and mine is from 24 May.

Problem also occurs on my machine using Win XP Home,
Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32
even just typing "print" at the interactive prompt causes a syntax error...

It __may__ be that this is caused by an error in the codecs machinery which is already
fixed in 2.4 CVS. Could you try this out?

Reinhold

[Lonnie Princehouse]

After doing some more reading, I now think this isn't a bug.

Evidently the unbuffered flag not only makes stdin unbuffered, but it
also forces it into binary mode. I didn't realize that when I posted
earlier.

So the SyntaxErrors arise because the interpreter isn't converting \r\n
into \n because stdin is binary. Not a bug, although it would be nice
to have an "unbuffered text mode" flag too...

D'oh.

[Michael Hoffman]

Lonnie Princehouse wrote:

Evidently the unbuffered flag not only makes stdin unbuffered, but it
also forces it into binary mode. I didn't realize that when I posted
earlier.

So the SyntaxErrors arise because the interpreter isn't converting \r\n
into \n because stdin is binary. Not a bug, although it would be nice
to have an "unbuffered text mode" flag too...

so if you do this:

z = raw_input()

zzz

Does z contain 'zzz\r'?

For me, it just contains 'zzz'.
--
Michael Hoffman

[Lonnie Princehouse]

Yes. With the unbuffered flag, raw_input() strings on my box end in
\r.

[Steve Holden]

Lonnie Princehouse wrote:

After doing some more reading, I now think this isn't a bug.

Evidently the unbuffered flag not only makes stdin unbuffered, but it
also forces it into binary mode. I didn't realize that when I posted
earlier.

So the SyntaxErrors arise because the interpreter isn't converting \r\n
into \n because stdin is binary. Not a bug, although it would be nice
to have an "unbuffered text mode" flag too...

D'oh.

It seems a little bizarre to me that the compiler isn't prepared to
treat carriage returns as whitespace during its tokenizations. The only
area I would anticipate problems would be string literals containing
end-of-line sequences embedded within triple-quotes.

It would seem to make sense to program the compiler defensively to
ignore embedded "\r" characters.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC http://www.holdenweb.com/