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
