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 tim.peters
Recipients Mark.Shannon, benjamin.peterson, christian.heimes, jdemeyer, larry, lukasz.langa, methane, miss-islington, nascheme, ned.deily, pablogsal, petr.viktorin, pitrou, tim.peters, vstinner
Date 2019-10-03.17:57:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Loose ends.  Telegraphic because typing is hard.

1. Docs should be changed to encourage implementing the full gc protocol for "all" containers.  Spell out what can go wrong if they don't.  Be upfront about that history has, at times, proved us too optimistic about that ever since weakrefs were added.

2. Surprise finalizers (SF).  All weakrefs to trash objects were already cleared.  So if a SF can access trash, it must be via a chain of strong refs.  But in that case, they wouldn't be trash to begin with (since they're reachable from the SF, which is a S because we believed it wasn't trash).

So best optimistic guess is that only this can go wrong:  we promise that a finalizer will run at most once (even if the object is resurrected), but a SF neither records that it has been run nor recognizes that (if so) it's already been run.  IOW, a finalizer will be run at most once when it's not a surprise, but will run every time it is a SF.

3. get_objects() exposing invalid objects.  That's no good.  Not due to missing tp_traverse, but that the aggregate of trash objects revealed by tp_traverses exceed the aggregate of those reclaimed by tp_clears and subsequent refcounting.

Must not move invalids to older generation.  Move to new internal (to delete_garbage) list instead.  That list should be empty at delete_garbage's end.  If not, I'd be happy to die with a fatal runtime error.  Else, e.g.,

- add to count of trash objects that could not be collected

- append them to gc.garbage, each as the sole attribute of a new (say) `_GCInvalid` container, whose repr/str only shows the address of the invalid object.  So the top-level objects in gc.garbage remain valid, but the daring can access the invalid objects indirectly.  At least their type pointers should be intact.
Date User Action Args
2019-10-03 17:57:54tim.peterssetrecipients: + tim.peters, nascheme, pitrou, vstinner, larry, christian.heimes, benjamin.peterson, ned.deily, petr.viktorin, methane, lukasz.langa, Mark.Shannon, jdemeyer, pablogsal, miss-islington
2019-10-03 17:57:54tim.peterssetmessageid: <>
2019-10-03 17:57:54tim.peterslinkissue38006 messages
2019-10-03 17:57:54tim.peterscreate