In article <[EMAIL PROTECTED]>,
"Sandra-24" <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-list
