Bugs item #1163244, was opened at 2005-03-15 07:20
Message generated for change (Comment added) made by mhammond
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim N. van der Leeuw (tnleeuw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Syntax error on large file with MBCS encoding
Initial Comment:
Large files generated by make-py.py from the win32all
extensions cannot be compiled by Python2.4.1rc1 - they
give a syntax error.
This is a regression from 2.3.5
(With Python2.4, the interpreter crashes. That is fixed
now.)
Removing the mbcs encoding line from the top of the
file, compilation succeeds.
File should be attached, as zip-file. Probably requires
win32all extensions to be installed to be compiled /
imported (generated using build 203 of the win32all
extensions).
----------------------------------------------------------------------
>Comment By: Mark Hammond (mhammond)
Date: 2005-03-21 23:11
Message:
Logged In: YES
user_id=14198
I believe this is a different bug than the recent
"long-lines" errors (see below). I can reproduce this with
a file that uses neither long lines, nor any pywin32
extensions (2.4 branch, trunk)
A Python source file containing:
-- start snippet --
# -*- coding: mbcs -*-
<1532 characters of code or comments>
<cr/lf newline>
x = {}
-- end snippet --
Will yield a SyntaxError when attempting to import the
module. Running the module as a script does not provoke the
error.
To reproduce, there must be exactly 1532 characters where
specified (see the attached file for a demo). Adding or
removing even a single character will prevent the error. It
is possible to replace characters with any others, including
valid code, and still see the error - however, the number of
characters must remain the same .cr/lf pairs can also be
replaced with any other 2 characters. There are other
"block sizes" that will provoke the error, but this is the
only one I have nailed.
Apart from the "block" of 1532 characters, the coding line
and the blank line before the dict assignment also appear
critical. Unlike the other characters in the block, this
last cr/lf pair can not be replaced with comments. I can't
provoke the error with other encodings (note there are no
encoded characters in the sample - it is trivial).
To reproduce, save the attached file on Windows and execute:
> python -c "import foo2"
Traceback (most recent call last):
File "<string>", line 1, in ?
File "foo2.py", line 24
x = {}
^
SyntaxError: invalid syntax
Note that Python 2.3 and earlier all work. Also note that
"python foo2.py" also works. The code is clearly valid.
Haven't tried to repro on Linux (mbcs isn't available there,
and I can't get a test case that doesn't use it)
Other pointers/notes: pywin32 bug 1085454 is related to
long-lines, by all accounts that underlying error has been
fixed - I can't verify this as pywin32 no longer generates
insanely long lines. I can confirm Python bugs
1101726/1089395 still crashes Python 2.3+. I believe all
(including this) are discrete bugs.
[foo2.py is my attachment - ya gotta love sourceforge :)]
----------------------------------------------------------------------
Comment By: Christos Georgiou (tzot)
Date: 2005-03-20 21:28
Message:
Logged In: YES
user_id=539787
Useful pointers: in Python-dev, this has been characterised
as related to pywin32 bug 1085454. Also related to
www.python.org/sf/1101726 and www.python.org/sf/1089395.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163244&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
