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 ncoghlan
Recipients barry, benjamin.peterson, isoschiz, ncoghlan, pitrou, sbt
Date 2013-04-20.15:27:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Calling __del__ explicitly shouldn't be any worse than doing the same thing for any other type implemented in Python (or, in the case of generators, calling close() multiple times). What I'm mostly interested in is the "can this type cause uncollectable cycles" introspection aspect.

However, as Antoine noted, generators are an interesting special case because the GC is able to *skip* finalising them in some cases, so exposing __del__ isn't right for them either (as that suggests they will *always* be uncollectable in a cycle, when that isn't the case).

So now I'm wondering if a better answer may be to generalise the current generator special case to a "__needsdel__" protocol: provide a __del__ method, but always make it possible for the GC to skip it when it wouldn't do anything (e.g. if you've already called close() explicitly). PyGenerator_NeedsFinalizing would then become the __needsdel__ impl for generators, and we could lose the special casing in the GC code. From Python, you could detect the three cases through:

__del__ only: can cause uncollectable cycles
__del__and __needsdel__: can cause uncollectable cycles, but it depends on the instance state
Neither: can't cause uncollectable cycles
Date User Action Args
2013-04-20 15:27:33ncoghlansetrecipients: + ncoghlan, barry, pitrou, benjamin.peterson, sbt, isoschiz
2013-04-20 15:27:33ncoghlansetmessageid: <>
2013-04-20 15:27:33ncoghlanlinkissue17800 messages
2013-04-20 15:27:32ncoghlancreate