This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author martin.panter
Recipients martin.panter, reidfaiv
Date 2016-03-10.13:15:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1457615744.94.0.696567592444.issue26528@psf.upfronthosting.co.za>
In-reply-to
Content
What is probably happening here is how garbage collection works at the interpreter exit. It is sort of mentioned in the warning at <https://docs.python.org/3/reference/datamodel.html#object.__del__>.

The variable g is an iterator for event_gen(), and it is still “alive” when the exception is raised. The exception contains a reference to the traceback and all the local variables, including g. So the context manager in the generator cannot exit until g is deleted [or g.close() is called].

In the “volatile exception” case, I guess it is easy for the interpreter to release the exception traceback, including the g iterator that it references, straight after it has reported the traceback.

But when you store an exception that you catch in a local variable, you create a reference loop (something like ee.__traceback__.tb_frame.f_locals["ee"] is ee). So it is not so easy to release the references, and by the time the garbage collector runs, I guess it has already set builtin names like “open” (global variable of the “builtins” module) to None.

If you need a generator to clean up, you should probably close the generator before exiting the function rather than relying on garbage collection. Unfortunately there is no mechanism like ResourceWarning to indicate this problem with generators.
History
Date User Action Args
2016-03-10 13:15:45martin.pantersetrecipients: + martin.panter, reidfaiv
2016-03-10 13:15:45martin.pantersetmessageid: <1457615744.94.0.696567592444.issue26528@psf.upfronthosting.co.za>
2016-03-10 13:15:44martin.panterlinkissue26528 messages
2016-03-10 13:15:44martin.pantercreate