I am getting "unknown parsing error" when trying to run a script with a following first line: #@+leo-encoding=cp1251. If I add a couple of empty lines or # -*- coding: cp1251 -*- then everything is ok. I am using ActiveState python 2.3.3 on Win2K server. ---------- Python ---------- error=22 File "test.py", line 1 SyntaxError: unknown parsing error Output completed (0 sec consumed) - Normal Termination ------------------------------ #@+leo-encoding=cp1251. #@+node:0::@file test.py #@+body for i in range(5): print i #@-body #@-node:0::@file test.py #@-leo
Logged In: YES user_id=33168 Martin, I hope you don't mind me assigning this to you. I think you implemented the coding spec. I briefly read the PEP and while the code does what the PEP states (ie, use a regex), the behaviour doesn't match the examples. It also seems like it could be error prone to allow r'#.*coding[:=]' I think there are two issues. 1) in pythonrun.c in E_DECODE there is a missing break 2) the check for # -*- coding is not strict enough The patch makes the check r'# (-\*-)? coding[:=]' The attached patch addresses both issues, although I'm not sure you will agree #2 is a problem. Feel free to checkin, assign back to me or whatever. I'm not sure what the error message in pythonrun should be, right now it's "unknown decode error." Perhaps that should be "invalid encoding" or something?
Logged In: YES user_id=21627 The patch is wrong. The PEP deliberately allows for arbitrary occurrences of the substring "coding", in particular inside "encoding". This was made so that other editors, like vi or LEO, can continue to use their own encoding declarations, and Python would recognize them. Unfortunately, LEO decided to add a full stop at the end of the line, so Python looks for an encoding named "cp1251.". We agree with the LEO author that this is a problem in LEO, and will be fixed. Alternatively, we could amend the PEP and declare that trailing dots are not part of the encoding name. The other part of the patch is correct; I have applied it as pythonrun.c 2.195.6.6 and 2.207. It would be even better if we could display the actual cause of the problem, but that is currently not supported in the parser.
