This issue tracker has been migrated to GitHub ,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2009年11月23日 10:04 by ghewgill, last changed 2022年04月11日 14:56 by admin. This issue is now closed.
| Files | ||||
|---|---|---|---|---|
| File name | Uploaded | Description | Edit | |
| traceback.patch | ghewgill, 2009年11月23日 10:04 | |||
| Messages (3) | |||
|---|---|---|---|
| msg95617 - (view) | Author: Greg Hewgill (ghewgill) | Date: 2009年11月23日 10:04 | |
Quite by accident, I came across a case where Python would quit
generating traceback text and skip printing the actual exception
information. Here is a sample program:
exec(compile("spam()", ".", "exec"))
and the output in Python 3.1 ("spam" is undefined):
$ python3.1 test.py
Traceback (most recent call last):
File "test.py", line 1, in <module>
exec(compile("spam()", ".", "exec"))
File ".", line 1, in <module>
$
This was bewildering until I realised that the traceback generator was
unable to read from the filename passed to compile() (my original
example was using a name other than "." that wasn't intended to be a
file name, but just happened to also be a directory name). I didn't
really mind the lack of source text, but the lack of the actual
exception message was most disturbing.
This appears to be a failure mode common to both traceback.c and
traceback.py, through slightly different mechanisms. In traceback.c, if
the source filename refers to a directory, the C open() succeeds but an
error occurs when trying to read from the directory handle. In
traceback.py, the Python open() call fails with an IOError exception,
and the exception wasn't handled gracefully.
I have attached a patch that creates the following output instead:
$ ./python.exe test.py
Traceback (most recent call last):
File "test.py", line 1, in <module>
exec(compile("spam()", ".", "exec"))
File ".", line 1, in <module>
[Errno 21] Is a directory: '.'
NameError: name 'spam' is not defined
$
I have tested the patch against Python 3.1, but it applies cleanly to
the trunk (for some reason I couldn't make the trunk build, but that's
unrelated). This patch may need some finesse for a Win32 build; I don't
have the ability to test that at the moment.
|
|||
| msg102669 - (view) | Author: Daniel Diniz (ajaksu2) * (Python triager) | Date: 2010年04月09日 02:01 | |
Patch still applies to py3k, not applying cleanly to trunk anymore. Tests pass with patch on py3k. |
|||
| msg179056 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) | Date: 2013年01月04日 17:50 | |
3.1 gets only security fixes. In 2.7 and 3.2+ the bug has already fixed. |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022年04月11日 14:56:55 | admin | set | github: 51627 |
| 2013年01月04日 17:50:24 | serhiy.storchaka | set | status: open -> closed nosy: + serhiy.storchaka messages: + msg179056 resolution: out of date stage: patch review -> resolved |
| 2010年04月09日 04:10:23 | ezio.melotti | set | nosy:
+ ezio.melotti versions: + Python 3.2 |
| 2010年04月09日 02:01:10 | ajaksu2 | set | priority: normal nosy: + ajaksu2 messages: + msg102669 stage: patch review |
| 2009年11月23日 10:04:20 | ghewgill | create | |