[issue2384] [Py3k] line number is wrong after encoding declaration

Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>: -- status: pending -> closed ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-

[issue2384] [Py3k] line number is wrong after encoding declaration

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Committed r66867. I had to considerably change the unit tests, because the subprocess output is not utf-8 encoded; it's not even the same as sys.stdout, because the spawned process uses a PIPE, not a terminal: on my winXP, the main

[issue2384] [Py3k] line number is wrong after encoding declaration

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: This issue depends on #3975 to properly display tracebacks from python files with encoding. -- dependencies: +PyTraceBack_Print() doesn't respect # coding: xxx header ___ Python tracker <[EM

[issue2384] [Py3k] line number is wrong after encoding declaration

Changes by STINNER Victor <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11738/tokenizer-coding-4.patch ___ Python tracker <[EMAIL PROTECTED]> ___

[issue2384] [Py3k] line number is wrong after encoding declaration

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11737/traceback_unicode-4.patch ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue2384] [Py3k] line number is wrong after encoding declaration

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11609/test_traceback-gbk.patch ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue2384] [Py3k] line number is wrong after encoding declaration

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11717/tokenizer-coding-3.patch ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue2384] [Py3k] line number is wrong after encoding declaration

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11625/tokenizer-coding-2.patch ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue2384] [Py3k] line number is wrong after encoding declaration

STINNER Victor <[EMAIL PROTECTED]> added the comment: @amaury: Ok, I added your long comment in tokenizer.c. You're also right about the strange code in the test. I reused ocean-city's test. "sys.exc_info()[2].tb_lineno" raises an additional (useless) error. So I simplified the code to use onl

[issue2384] [Py3k] line number is wrong after encoding declaration

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Your patch does the correct thing, however an explanation of the -1 value would be welcome. Something like: /* The file has been reopened; parsing will restart from * the beginning of the file, we have to reset the line number. * But

[issue2384] [Py3k] line number is wrong after encoding declaration

STINNER Victor <[EMAIL PROTECTED]> added the comment: benjamin was afraid by the comment /* dirty hack */ in my previous comment. After reading tokenizer.c again and again, I can say that the fix is correct: the file is closed and then re-opened by fp_setreadl() (using io.open()), and so the f

[issue2384] [Py3k] line number is wrong after encoding declaration

STINNER Victor <[EMAIL PROTECTED]> added the comment: Issue 2832 is a duplicate. ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list

[issue2384] [Py3k] line number is wrong after encoding declaration

Changes by STINNER Victor <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11610/tokenizer-coding.patch ___ Python tracker <[EMAIL PROTECTED]> ___

[issue2384] [Py3k] line number is wrong after encoding declaration

STINNER Victor <[EMAIL PROTECTED]> added the comment: @ocean-city: Oops, sorry. Using your patch (set lineno in fp_setreadl()), it works on both cases ("python test.py" or "python -m test"). The new patch includes your fix for tokenizer.c and a new version of the testcase. Added file: http://bu

[issue2384] [Py3k] line number is wrong after encoding declaration

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment: Victor, this is fp_setreadl's problem, so if put "tok->lineno = -1" anywhere, it should be in fp_setreadl(), I think. r = set_readline(tok, cs); if (r) { /* 1 */ tok->encoding = cs;

[issue2384] [Py3k] line number is wrong after encoding declaration

STINNER Victor <[EMAIL PROTECTED]> added the comment: Oh! My patch breaks "python -m". The problem is maybe no in the token parser but... somewhere else? --- test.py --- # coding: ASCII raise Exception("line 2") # try again! --- Python 3.0 trunk unpatched: --- $ ./python test.py Tra

[issue2384] [Py3k] line number is wrong after encoding declaration

STINNER Victor <[EMAIL PROTECTED]> added the comment: Here is a patch fixing this issue: it's quite the same that ocean-city patch, but I prefer to patch lineno only if set_readline() succeed. About the truncated traceback for multibyte charset: see the new issue3975. Added file: http://bugs.

[issue2384] [Py3k] line number is wrong after encoding declaration

STINNER Victor <[EMAIL PROTECTED]> added the comment: Hum, about the empty line error using a multibyte charset, the issue is different. PyTraceBack_Print() calls _Py_DisplaySourceLine() which doesn't take care of the charset. ___ Python tracker <[EMAIL PROT

[issue2384] [Py3k] line number is wrong after encoding declaration

STINNER Victor <[EMAIL PROTECTED]> added the comment: ocean-city testcase is invalid: it uses subprocess.call() which returns the exit code, not the Python error line number! Here is a better testcase using subprocess.Popen() checking the line number but also the display line. It tests ASCII,

[issue2384] [Py3k] line number is wrong after encoding declaration

STINNER Victor <[EMAIL PROTECTED]> added the comment: By setting lineto to 1 (as proposed ocean-city), ASCII tests (test1 and test2, see below) works correctly. This change doesn't impact utf-8/iso-8859-1 charset (it's special case). --- test1 --- # coding: ASCII raise Exception("here") --

[issue2384] [Py3k] line number is wrong after encoding declaration

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: #3973 is a duplicate. -- nosy: +pitrou ___ Python tracker <[EMAIL PROTECTED]> ___

[issue2384] [Py3k] line number is wrong after encoding declaration

Changes by Antoine Pitrou <[EMAIL PROTECTED]>: -- nosy: +haypo ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mailing l

[issue2384] [Py3k] line number is wrong after encoding declaration

Jean-Michel Fauth <[EMAIL PROTECTED]> added the comment: Python 3.0rc1 If the lines are now displayed correctly, I think there is still a numbering issue, a +1 offset. Python 2.5.2 # -*- coding: cp1252 -*- line 1, first line s = 'abc' import dummy s = 'def' --- >pythonw -u "testpy

[issue2384] [Py3k] line number is wrong after encoding declaration

Dwayne Litzenberger <[EMAIL PROTECTED]> added the comment: Could "-*- coding: ascii -*-" and other equivalent encodings be fixed, at least, before the release? ___ Python tracker <[EMAIL PROTECTED]> __

[issue2384] [Py3k] line number is wrong after encoding declaration

Changes by Dwayne Litzenberger <[EMAIL PROTECTED]>: -- nosy: +dlitz ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mail

[issue2384] [Py3k] line number is wrong after encoding declaration

Jean-Michel Fauth <[EMAIL PROTECTED]> added the comment: Py3.0b2. This bug seems to be quite annoying. Especially when one works with a main module importing modules which are importing modules and so on, all modules having an encoding declaration. The Traceback (and the user) is (are) a little b

[issue2384] [Py3k] line number is wrong after encoding declaration

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment: While this is a bug, it's not serious enough to hold up the release. -- priority: release blocker -> high ___ Python tracker <[EMAIL PROTECTED]>

[issue2384] [Py3k] line number is wrong after encoding declaration

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- priority: critical -> release blocker ___ Python tracker <[EMAIL PROTECTED]> ___ __

[issue2384] [Py3k] line number is wrong after encoding declaration

Barry A. Warsaw <[EMAIL PROTECTED]> added the comment: This is a bug and not a new feature, so it could go in after beta. I'm knocking it down to a critical. -- nosy: +barry priority: release blocker -> critical ___ Python tracker <[EMAIL PROTECTED]>

[issue2384] [Py3k] line number is wrong after encoding declaration

Changes by Georg Brandl <[EMAIL PROTECTED]>: -- priority: -> release blocker __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing lis

[issue2384] [Py3k] line number is wrong after encoding declaration

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment: I've written testcase for lineno problem. -- keywords: +patch Added file: http://bugs.python.org/file9943/test_traceback.patch __ Tracker <[EMAIL PROTECTED]> _

[issue2384] [Py3k] line number is wrong after encoding declaration

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment: Following dirty hack workarounds this bug. Comment of this function says not ascii compatible encoding is not supported yet, (ie: UTF-16) so probably this works. Index: Parser/tokenizer.c ===

[issue2384] [Py3k] line number is wrong after encoding declaration

New submission from Hirokazu Yamamoto <[EMAIL PROTECTED]>: # This issue inherits from issue2301. If there is "# coding: " is in source code and coding is neigher utf-8 nor iso-8859-1, line number (tok->lineno) becomes wrong. Please look into Parser/tokenizer.c. In this case, tok->decoding_