On Sat, 8 Mar 2014 16:14:23 +0100 Victor Stinner <victor.stin...@gmail.com> wrote: > 2014-03-08 14:33 GMT+01:00 Antoine Pitrou <solip...@pitrou.net>: > > Ok, it's actually quite trivial. The whole chain is kept alive by the > > "fut" global variable. If you arrange for it to be disposed of: > > > > fut = asyncio.Future() > > asyncio.Task(func(fut)) > > del fut > > [etc.] > > > > then the problem disappears: as soon as gc.collect() happens, the > > MyObject instance is destroyed, the future is collected, and the > > future's traceback is printed out. > > Well, the problem is more general than this specific example. I would > like to implement a general solution which would not hold references > to local variables, to destroy objects when Python exits the except > block.
How about the following patch: diff --git a/Lib/asyncio/futures.py b/Lib/asyncio/futures.py --- a/Lib/asyncio/futures.py +++ b/Lib/asyncio/futures.py @@ -315,6 +315,7 @@ class Future: self._schedule_callbacks() if _PY34: self._log_traceback = True + self._loop.call_soon(traceback.clear_frames, exception.__traceback__) else: self._tb_logger = _TracebackLogger(exception, self._loop) # Arrange for the logger to be activated after all callbacks That said, I agree an automated mechanism would be useful. It is overwhelmingly rare to want to analyze local variables in a traceback, yet Python always keeps a reference to those. Perhaps tracebacks could have a __debug__ attribute which, when sent to False, would prevent the locals from being kept alive (but how?). Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com