Antoine Pitrou wrote:
On Sun, 27 Jun 2010 19:20:07 +0200 "M.-A. Lemburg" firstname.lastname@example.org wrote:
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?
IIUC, the traceback object will still be alive during processing of the except clause, so all you'd have to do is turn the weak reference into a real one. Let's assume that the weakref object is called .__traceback_weakref__ and the proxy called .__traceback__ (to assure compatibility).
... except TypeError as exc:
# Replace the weakref object with the referenced object exc.__traceback__ = exc.__traceback_weakref__()
# Set the weakref object to None to have it collected and to # signal this operation to other code knowing about this # strategy. exc.__traceback_weakref__ = None
BTW: I wonder why proxy objects don't provide a direct access to the weakref object they are using. That would make keeping that extra variable around unnecessary.
Besides, an API which gives some information in an unreliable manner does not seem very user-friendly to me.
The argument so far has been that most error processing happens in the except clause itself, making it unnecessary to deal with possible circular references. That is certainly true in many cases.
Now under that argument, using the traceback stored on an exception outside the except clause is even less likely to be needed, so I don't follow your concern that using a weak reference is less user-friendly.
Perhaps someone could highlight a use case where the traceback is needed outside the except clause ?!
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.
It's certainly a good idea to pay extra attention to this in Python3.