On 28 June 2010 04:00, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 27 Jun 2010 19:20:07 +0200
> Not necessarily roll back the feature, but an implementation
> that deliberately introduces circular references is not really
> ideal.
>
> Since tracebacks on exceptions are rarely used by applications,
> I think it would be better to turn them into weak references.
How do you manage to get a strong reference before the traceback object
gets deleted?
At the beginning of the 'except' block, a strong local (but hidden) reference is obtained to the traceback (if it exists). This is deleted at the end of the 'except' block.
Besides, an API which gives some information in an unreliable manner
does not seem very user-friendly to me.
I think I like the OP's idea better: allow to release the references to
local and global variables from the frames in the traceback. This is
keeps a lot of potentially large objects alive - some of which may also
keep some OS resources busy.
I agree, with a variation - keep a weak reference to the frame in the traceback, and have a way for the application to specify that it wants to retain strong references to frames (so unittest for example can guarantee access to locals and globals). Possibly a context manager could be used for this, and decorators could be used to wrap an entire method in the context manager.
A dummy frame would also be stored that contained enough info to replicate the existing stack trace (file, line number, etc). A strong reference could be obtained via the existing attribute, converted to a property, which does:
a. return the internal reference if it is not a dummy frame;
b. return the result of the weak reference if it still exists;
c. return the dummy frame reference.
I think this gives us the best of all worlds:
1. No strong reference to locals/globals in tracebacks by default;
2. Able to force strong references to frames;
3. We don't lose the ability to compose a full and complete stack trace.
Tim Delaney