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]
http://bugs.python.org/issue3975
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
Changes by STINNER Victor [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file11748/traceback_unicode-5.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3975
___
Changes by STINNER Victor [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11747/traceback_unicode-5.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3975
___
Changes by STINNER Victor [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11736/traceback_unicode-4.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3975
___
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;
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.
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]
http://bugs.python.org/issue3975
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 released
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
The line is not displayed (why? no idea)
Well, it's difficult to re-open stdin...
--
nosy: +amaury.forgeotdarc
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3975
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 always
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', (...)]
Changes by STINNER Victor [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file11732/traceback_unicode-3.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3975
___
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() macro
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
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
Changes by STINNER Victor [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11612/traceback_unicode.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3975
___
Changes by STINNER Victor [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11633/traceback_unicode-2.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3975
___
Changes by STINNER Victor [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11732/traceback_unicode-3.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3975
___
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,
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
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 line
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]
http://bugs.python.org/issue3975
23 matches
Mail list logo
