[Twisted-Python] Tracebacks being dropped from exceptions when using inlineCallbacks

[Christopher Armstrong]

On Fri, Jan 16, 2009 at 7:28 PM, Phil Christensen <phil at bubblehouse.org> wrote:
> The comment was this:
>
>        # added 2003-06-23 by Chris Armstrong. Yes, I actually have a
>        # use case where I need this traceback object, and I've made
>        # sure that it'll be cleaned up.
>        self.tb = tb
>
> presumably referring to the problem with keeping references to tracebacks
> that was a potential pitfall in the Python version of that time. That's a
> non-issue since Python 2.2, though, which is probably why the comment got
> deleted.

Keeping references to tracebacks still has many potential pitfalls.
It's a fundamental problem: tracebacks refer to all their frames,
which refer to all their locals; this makes it *really* easy to create
uncollectable cycles if you have any __del__ methods *anywhere*. It's
just not safe to keep the traceback reference in the general case.
Failure needs to work with arbitrary code.

> Originally all __getstate__ did was stringify the object's state, which is
> probably why cleanFailure calls it directly. It looks to me like most of the
> code from __getstate__ should really be moved into a separate method, which
> would be called from cleanFailure as well as __getstate__.

Sure, that would be a slightly better factoring.

> This assumes that __getstate__ would still set c['tb'] to None, but that
> cleanFailure would not. I'm not sure what the repercussions of this would
> be, though. It seems the old problem with keeping references to tracebacks
> is less of an issue now, based on this from the current Python docs:
>
>> Note Beginning with Python 2.2, such cycles are automatically reclaimed
>> when garbage collection is enabled and they become unreachable, but it
>> remains more efficient to avoid creating cycles.
>
> I'd appreciate any feedback.
>
> -phil

-- 
Christopher Armstrong
http://radix.twistedmatrix.com/
http://planet-if.com/
http://canonical.com/