[Python-Dev] Evil reference cycles caused Exception.traceback (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Mon Sep 18 12:50:40 EDT 2017
- Previous message (by thread): [Python-Dev] Evil reference cycles caused Exception.__traceback__
- Next message (by thread): [Python-Dev] Evil reference cycles caused Exception.__traceback__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, 18 Sep 2017 09:42:45 -0700 Nathaniel Smith <njs at pobox.com> wrote:
Obviously it's nice when the refcount system is able to implicitly clean things up in a prompt and deterministic way, but there are already tools to handle the cases where it doesn't (ResourceWarning, context managers, ...), and the more we encourage people to implicitly rely on refcounting, [...]
The thing is, we don't need to encourage them. Having objects disposed of when the last visible reference vanishes is a pretty common expectation people have when using CPython.
Why are reference cycles a problem that needs solving?
Because sometimes they are holding up costly resources in memory when people don't expect them to. Such as large Numpy arrays :-)
And, no, there are no obvious ways to fix for users. gc.collect() is much too costly to be invoked on a regular basis.
Because if so then that seems like a bug in the warnings mechanism; there's no harm in a dead Thread hanging around until collected, and Victor may have wasted a day debugging an issue that wasn't a problem in the first place...
Yes, I think Victor is getting a bit overboard with the so-called "dangling thread" issue. But the underlying issue (that heavyweight resources can be inadvertently held up in memory up just because some unrelated exception was caught and silenced along the way) is a real one.
Regards
Antoine.
- Previous message (by thread): [Python-Dev] Evil reference cycles caused Exception.__traceback__
- Next message (by thread): [Python-Dev] Evil reference cycles caused Exception.__traceback__
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]