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 brandtbucher
Recipients brandtbucher, nascheme, pablogsal, tim.peters
Date 2020-10-09.23:19:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1602285576.48.0.594991960676.issue41984@roundup.psfhosted.org>
In-reply-to
Content
> Maybe I am missing something but we could mark them as having GC support unconditionally but still leave them untracking and unconditionally add a tracking call on setattribute.

Hm, I’m not sure that would be enough. Consider the case of a class that registers its instances in a collection of some sort:

while True:
    class D:
        __slots__ = ()
        registry = []
        def __init__(self):
            self.registry.append(self)
    for i in range(100):
        D() and None  # Suppress REPL output.
    del D

This is probably more common (and problematic) than my example above.

At the same time, I agree that it’s not *ideal* to track all of these objects automatically. Anyone setting __slots__ is probably planning on creating lots of “cheap” instances. If they do accidentally create cycles, though, I feel the memory hit then would be worse than any collection overhead.

I’m just not sure I see a way to fix this without tracking them all.
History
Date User Action Args
2020-10-09 23:19:36brandtbuchersetrecipients: + brandtbucher, tim.peters, nascheme, pablogsal
2020-10-09 23:19:36brandtbuchersetmessageid: <1602285576.48.0.594991960676.issue41984@roundup.psfhosted.org>
2020-10-09 23:19:36brandtbucherlinkissue41984 messages
2020-10-09 23:19:36brandtbuchercreate