[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
More information about the Python-Dev mailing list
Sat Mar 8 16:14:23 CET 2014
- Previous message: [Python-Dev] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
- Next message: [Python-Dev] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
- Next message: [Python-Dev] What is the precise problem? [was: Reference cycles in Exception.__traceback__]
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list