[issue7340] Doc for sys.exc_info has warning that is no longer valid

[Greg Hewgill]

New submission from Greg Hewgill :

Based on a short discussion on python-dev: 
http://mail.python.org/pipermail/python-dev/2009-November/094306.html

the "Warning" box in the documentation for sys.exc_info needs to be 
updated in light of PEP 3134, and perhaps moved elsewhere since the 
circular reference problem can now occur whether or not the traceback 
returned by sys.exc_info is used.

It might also be worth mentioning that the way to break the circular 
reference, if necessary, is to explicitly set the __traceback__ member 
of the handled exception to None.

--
assignee: georg.brandl
components: Documentation
messages: 95393
nosy: georg.brandl, ghewgill
severity: normal
status: open
title: Doc for sys.exc_info has warning that is no longer valid
type: behavior
versions: Python 3.0, Python 3.1, Python 3.2

___
Python tracker 
<http://bugs.python.org/issue7340>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7378] unexpected truncation of traceback

[Greg Hewgill]

New submission from Greg Hewgill :

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 
exec(compile("spam()", ".", "exec"))
  File ".", line 1, in 
$

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 
exec(compile("spam()", ".", "exec"))
  File ".", line 1, in 
[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.

--
components: Interpreter Core, Library (Lib)
files: traceback.patch
keywords: patch
messages: 95617
nosy: ghewgill
severity: normal
status: open
title: unexpected truncation of traceback
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15384/traceback.patch

___
Python tracker 
<http://bugs.python.org/issue7378>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com