It is a quite common pitfall in python: trying to directly use knowledge gathered within other programming languages, like Java or .NET.
And, usually, ends with something like “Puah, I don’t like python”.
For instance, garbage collection.
Mainly, Python memory management is implemented through reference counting: as soon as the number of references of an object reaches zero, it is deleted. What “delete” means, then, depends on the actual implementation of the python VM.
CPython, for instance, uses delete the object: this means that the C++ destructor (or, in case of Python objects, the __del__ method) is called, and the memory may be released (or may return to a common pool handled directly by the python memory manager, in case of “simple” objects like integers); in other words, CPython uses deterministic finalizers.
However, this behavior is not guaranteed on other implementations, like JPython or IronPython, because of the different underlying memory model.
Reference counting has several advantages because it is easy to implement, fast, and predictable; on the other hand, it is not able to handle some cases, in particular circular references.
Circular references happens when items in a container maintain a reference to the container itself; in this particular situation, when the container goes out of scope its reference count will still remain higher than zero, and hence will cause a memory leak.
For this reason, since Python 2.0, there is a new module, called gc, that perform some garbage collecting.
Its main and sole purpose is to handle those particular situations, and does not change nothing on standard memory management.
Back to our initial problem, this is quite a big difference with, for instance, C#, where calling GC.Collect() will effectively deallocate all pending objects. In python, gc.collect() will simply run a “check” for circular references, and deallocate if necessary all pending object in such state.
This is the reason why, in case of problems with memory deallocation, calling gc.collect() in python is in most cases almost useless.
In python, such problems are symptoms of flaws in the design, and blaming the language because it does not behave like other certainly do not help fixing them.