[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: Committed r66867, together with #2384. Thanks for your perseverance ;-) -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]>

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

STINNER Victor <[EMAIL PROTECTED]> added the comment: My patch for #2384 contains a testcase which require #3975 and #2384 to be fixed (you have to apply both patches to test it). ___ Python tracker <[EMAIL PROTECTED]> _

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: The code is indeed easier to follow. I don't have any more remark, thanks to you perseverance! Now, is there some unit test we could provide? #2384 depends on this issue, it should be easy to extract a small test case.

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

Changes by STINNER Victor <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11748/traceback_unicode-5.patch ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

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

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

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

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

STINNER Victor <[EMAIL PROTECTED]> added the comment: @amaury: Oops, yes, I introduced a refleak in the version 4 with the PyUnicode_Check(). Instead of just moved Py_(X)RECREF(lineobj);, I could not not resist to refactor the code to remove one more indentation level (I prefer if (...) return

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

STINNER Victor <[EMAIL PROTECTED]> added the comment: > More fun will arise when my Windows terminal (encoding=cp1252) > will try to display Chinese characters. Let's pretend this is > yet another issue. I tried the patch using a script with unicode characters (character not representable in

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

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

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

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

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

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

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: One last thing: there is a path where lineobj is not freed (when PyUnicode_Check(lineobj) is false); I suggest to move Py_XDECREF(lineobj) just before the final return statement. Reference counting is fun ;-) > Should I stop on the fi

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

STINNER Victor <[EMAIL PROTECTED]> added the comment: Thanks for your remarks amaury. I improved my patch: - PyMem_FREE(found_encoding) is called just after PyFile_FromFd() - Create static subfunction _Py_FindSourceFile(): find a file in sys.path - Consider that sys.path contains only unicode

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: I still have remarks about traceback_unicode-3.patch, that I did not see before: - (a minor thing) PyMem_FREE(found_encoding) could appear only once, just after PyFile_FromFd. - I feel it dangerous to call the PyUnicode_AS_UNICODE() macr

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

Changes by STINNER Victor <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11732/traceback_unicode-3.patch ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: > Ok, O_BINARY and GIL fixed. which patch? ;-) > I just realized that sys.path is considered as a bytes string > (PyBytes_Check) whereas Python3 uses an unicode string! > > ['', '/home/haypo/prog/python-ptrace', (...)] > >>> sys.path.a

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

STINNER Victor <[EMAIL PROTECTED]> added the comment: Le Tuesday 07 October 2008 15:06:01 Amaury Forgeot d'Arc, vous avez écrit : > - The two calls to open() are missing the O_BINARY flag, necessary on > Windows to avoid newline translation. This may be important for some > codecs. Oops, I alway

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: The patch goes in the good direction, here are some remarks: - The two calls to open() are missing the O_BINARY flag, necessary on Windows to avoid newline translation. This may be important for some codecs. - the GIL should be release

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment: > The line is not displayed (why? no idea) Well, it's difficult to re-open ... -- nosy: +amaury.forgeotdarc ___ Python tracker <[EMAIL PROTECTED]> _

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

STINNER Victor <[EMAIL PROTECTED]> added the comment: Ooops, my first version introduces a regression: if file open fails, the traceback printing was stopped. Here is a new version of my patch to support #coding: header in _Py_DisplaySourceLine(). It doesn't print the line of file open fails,

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

STINNER Victor <[EMAIL PROTECTED]> added the comment: (oops, first patch included an useless whitespace change) Added file: http://bugs.python.org/file11612/traceback_unicode.patch ___ Python tracker <[EMAIL PROTECTED]>

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

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

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

STINNER Victor <[EMAIL PROTECTED]> added the comment: Here is a new version of _Py_DisplaySourceLine() using PyTokenizer_FindEncoding() to read the coding header, and PyFile_FromFd() to create an "unicode-awake" file. The code could be optimized, but it least it displays correctly the file lin

[issue3975] PyTraceBack_Print() doesn't respect # coding: xxx header

New submission from STINNER Victor <[EMAIL PROTECTED]>: PyTraceBack_Print() doesn't take care of the "# coding: xxx" header of a Python script. It calls _Py_DisplaySourceLine() which opens the file as a byte stream (and not an unicode characters stream). Because of this problem, the traceback