On Thu, Dec 12, 2019 at 1:33 PM Daniel Haude <dha...@posteo.de> wrote: > > Am 10.12.2019 22:29 schrieb Chris Angelico: > > > And once again, you are maintaining your assumptions despite being > > very clearly shown that they are wrong. "del instance" does not > > directly call __del__ any more than "instance = 1" does. You HAVE been > > shown. > > Much of the confusion in this thread comes from the murky distinction > between "garbage collection" and "memory management." I wouldn't call a > reference-counting system "garbage collection" per se.
https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Reference_counting It's definitely garbage collection. The alternative to a GC is explicitly choosing to free something, which is what usually happens when you program in C. > Another bone of contention seems to be the question exactly WHEN > reference counting and/or garbage collection release an object's > resources (give it back to memory management). I read the word "when" in > the non-implementation-specific Python docs as "immediately upon" (quote > below, caps by me): > > "Note: del x doesn’t directly call x.__del__() — the former decrements > the reference count for x by one, and the latter is only called WHEN x’s > reference count reaches zero." > > It is then up to Python's memory management (PyMem_Alloc et al in > CPython) what to do, and when: Give it back to the OS, keep it around > for later use, whatever. The most important distinction, which that note is emphasizing, is that the "del" statement removes just one reference, and if there are other references, then __del__ will not be called. None of this is about memory per se, but about objects; Python (the language) doesn't say anything about memory, but CPython (the implementation) does. So, for instance, *any* conformant Python implementation will have the semantics that "a = Thing(); b = a; del a" will not call Thing.__del__, because that thing still exists; but once all references expire, a conformant implementation is allowed to hand memory back to the OS immediately, or to manage its own memory pages and only hand those back when they're empty, or even to just not relinquish memory at all (granted, that would almost certainly be suboptimal, but it's not violating Python's semantics). We've been talking about garbage collection at the level of objects. When is an object disposed of? In CPython, this happens when its reference count hits zero, either naturally or when the cycle detector breaks a cycle. In Jython, I'm not sure, and I think it's based on the underlying Java interpreter's garbage collector. In a hypothetical but fully-conformant Python implementation, there could be a stop-the-world mark-and-sweep GC that runs every time a function returns, or every 250 bytecode instructions, or something. None of this cares about actual memory or when it gets returned to the system; it's all about when objects get destroyed. And regardless of the GC implementation, "del x" has the same effect as "x = None" as regards the previous value in x: they both just remove one reference. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
