Why did someone write this?

[Donn Cave]

In article <1144446670.262116.315360 at j33g2000cwa.googlegroups.com>,
 "Sandra-24" <sandravandale at 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, donn at u.washington.edu