del should call __del__ method

[blazewicz]

Example test with custom object:

class Foo():
    def __del__(self):
        print('__del__')

f = Foo()
del f  # should print '__del__'

Also for builtin types with finaliser, like socket.socket.
Example case:

s = socket.socket()
s.connect(addr)  # binds "hard" socket to object `s`
...
del s  # s.close() has not been called - "hard" socket will never be released

[dpgeorge]

This is not strictly a bug. CPython docs say "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." See https://docs.python.org/3/reference/datamodel.html#object.__del__

Workaround would be to call gc.collect() after doing the del. Then it should collect the object and call the finaliser.

Additional workaround for socket would be to call s.close() instead of doing del s.

Did you hit a problem with this in real code?

[stinos]

The 'real python' way would imo be context managers, i.e. __enter__ and __exit__ methods. If you add them to your Foo class you'd have a nice situation like

with Foo() as f:  # calls __enter__
  pass
# __exit__ called when f goes out of scope

# ... some time later ....
import gc
gc.collect()  # f is out of scope so it's finaliser will be called

[peterhinch]

My understanding is that good coding practice is to assume that __del__() may never be called at all.

[dpgeorge]

Closed in favour of #1878.