A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2014-March/132991.html below:

[Python-Dev] What is the precise problem? [was: Reference cycles in Exception.__traceback__]

[Python-Dev] What is the precise problem? [was: Reference cycles in Exception.__traceback__] [Python-Dev] What is the precise problem? [was: Reference cycles in Exception.__traceback__]Victor Stinner victor.stinner at gmail.com
Sat Mar 8 16:14:23 CET 2014
2014-03-08 14:33 GMT+01:00 Antoine Pitrou <solipsis at 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.

It looks like a "exception summary" containing only data to format the
traceback would fit asyncio needs. If you don't want it in the
traceback module, I will try to implement it in asyncio.

It would be nice to provide an "exception summary" in the traceback
module, because it looks like reference cycles related to exception
and/or traceback is a common issue (see the list of links I gave in a
previous email).

Victor
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4