Hacker News Reader

Comment by conistonwater | Hacker News Reader

Perhaps it's to make sure all the objects' finalizers are run also, making sure to release everything, not just memory and file descriptors? The finalizers are user-defined, so could include side effects that the GC would not know about.

View on HN

Does Python guarantee that finalizers are called at all? Most languages don't, I thought.

PEP 442 describes the situation with good detail, including how it was in Python 2 and how Python 3 improves on it:

https://www.python.org/dev/peps/pep-0442/

I know Haskell does: https://hackage.haskell.org/package/base-4.9.1.0/docs/Foreig... I'm not sure finalizers make sense without a guarantee they will eventually be called. But Haskell, for example, makes no guarantees about when it will be called, between the moment the last reference is lost and the moment the program exits.

Python seems to, too: https://docs.python.org/3/library/weakref.html, "When the program exits, each remaining live finalizer is called unless its atexit attribute has been set to false. They are called in reverse order of creation."

Do they need to be run in a specific order? Could you maintain a linked list of all objects, and at exit go through it at exit and run the finalizes? Might be faster than actually reclaiming the memory as well.

Maintaining that list through the whole process duration just to use it in the end sounds expensive, both in CPU and memory terms.

Reply on news.ycombinator.com