Why did someone write this?

[Sandra-24]

try:
exc_type, exc_value, exc_traceback = sys.exc_info()
# Do something
finally:
exc_traceback = None

Why the try/finally with setting exc_traceback to None? The python docs
didn't give me any clue, and I'm wondering what this person knows that
I don't.

Thanks,
-Sandra

[skip]

Sandra> try:
Sandra> exc_type, exc_value, exc_traceback = sys.exc_info()
Sandra> # Do something
Sandra> finally:
Sandra> exc_traceback = None

Sandra> Why the try/finally with setting exc_traceback to None?

The intent is to decrement the reference count to any objects referenced by
exc_traceback. Without it, the frame(s) referenced by the traceback remain
alive until exc_traceback goes out of scope.

Skip

[Benjamin Niemann]

Sandra-24 wrote:

try:
exc_type, exc_value, exc_traceback = sys.exc_info()
# Do something
finally:
exc_traceback = None

Why the try/finally with setting exc_traceback to None? The python docs
didn't give me any clue, and I'm wondering what this person knows that
I don't.

You just have not found the right part of the doc:
http://docs.python.org/lib/module-sys.html#l2h-337

--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://pink.odahoda.de/

[Sandra-24]

I can't believe I missed it in the documentation. Maybe it wasn't in
the offline version I was using, but more likely it was just one of
those things.

So the trouble seems to be that the traceback holds a reference to the
frame where the exception occurred, and as a result a local variable
that references the traceback in that frame now holds a reference to
it's own frame (preventing the frame from being recliamed) and can't be
cleaned up prior to python 2.2 with GC enabled.

Which means it's fine to hold a reference to the traceback in a frame
not in the traceback, or (I think) to create a temporary unamed
reference to it.

Thanks for your help guys!
-Sandra

[Donn Cave]

In article <11**********************@j33g2000cwa.googlegroups .com>,
"Sandra-24" <sa***********@yahoo.com> wrote:

I can't believe I missed it in the documentation. Maybe it wasn't in
the offline version I was using, but more likely it was just one of
those things.

So the trouble seems to be that the traceback holds a reference to the
frame where the exception occurred, and as a result a local variable
that references the traceback in that frame now holds a reference to
it's own frame (preventing the frame from being recliamed) and can't be
cleaned up prior to python 2.2 with GC enabled.

Which means it's fine to hold a reference to the traceback in a frame
not in the traceback, or (I think) to create a temporary unamed
reference to it.

I don't think that's exactly it - the problem wasn't exactly
circularity, and GC wouldn't help. But as I try to write a
test program that demonstrates, it looks like current versions
of Python have done something with sys.exc_traceback that
avoids at least some of the problems.

import sys
class A:
def __del__(self):
print 'A.__del__'

def f():
a = A()
try:
xyz
except:
print 'caught expected error'
print 'returning from f'
return sys.exc_traceback

t = f()
print 'Done'
In order to get the traceback to preserve "a" past its
natural lifetime, I had to return it to the caller, because
today sys.exc_traceback disappears when f() returns. But
it shows the effect on order of execution: 'A.__del__'
will appear after 'Done', when it should appear before it.

When I did this (sys.exc_traceback = None), the applications
used a terminal graphics library, like curses, and I often
depended on finalization (__del__) to run the "close" rendering
for a graphic element. Worked fine until an exception, so I
add this precaution to every I/O flush.

Donn Cave, do**@u.washington.edu