Re: Unwanted Python Persistent References
Yeah, skimming, you've got lots of cyclic references, then you put __del__ on everything.
Have you read the aforementioned gc module? I was really hoping not to have to do explanatory groundwork, but looking at it for you, gc.collect, gc.get_referrers, and gc.get_referents should all be useful in debugging.
But frankly the *entire* point of using a gc language is that it's supposed to be a black box that you don't see inside. You're not going to find docs on it. It's going to do surprising things. It may not return memory to the OS. I know that very old versions of Python even had bugs/difficulties around __del__ and cycles because it couldn't tell what order to delete objects in. These days that should be fixed, I believe, but the point stands. As long as those surprising things aren't using unreasonable amounts of memory, leave it alone. If knowing the lifetimes of things and when they get destroyed is this important to you, the only way you're going to get satisfactory answers is to use C++ or Rust.
You *can* have memory leaks because of this problem. But you haven't actually come to us and shown us one. If you want to do the test properly, you need to write one that pushes say 100000 levels onto Earwax, possibly as many as millions, so that you can be sure that memory growth is actually coming from where you think, then remove them all and see what happens, either using __del__ or weakref to find out when objects get deleted (except: __del__ might change behavior and weakref is better for this purpose). A bit of increased memory and some objects that don't get destroyed when you think in a short and simple program isn't a bug, it's a properly functioning gc, and even arguably a feature of gcs that lets them avoid a ton of OS calls.
It's like this. Writing an efficient gc isn't just "where are the references? Huh, none left, delete the thing". People literally spend years and years on just one of them, and make entire careers of being the GC guy. Python's GC ends up being relatively predictable, but only because Python eats the cost of reference counting instead of leaving it to one of the more complicated strategies. The only way to get a satisfactory answer as to how long something might stay around after __del__ is called is going to be to read the Python C source code.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
