__del__: when to use it? What happens when you SystemExit/NameError wrt del? Method vs function calls.

[Chris Angelico]

On Mon, Mar 7, 2016 at 2:27 PM, Veek. M <vek.m1234 at gmail.com> wrote:
> 1. What are the rules for using __del__ besides: 'don't use it'.

Use it as a last-shot cleanup of resources you own. Don't depend on
it, but use it.

> 2. What happens when I SystemExit? __del__ and gc are not invoked when I
> SystemExit and there's a circular reference - but why? The OS is going
> to reclaim the memory anyways so why be finicky about circular
> references - why can't we go ahead and call __dell_ and run gc?

SystemExit is an exception, same as any other (albeit one that doesn't
inherit from Exception, so it's usually left uncaught); the assumption
is that all resources will be cleaned up on process termination
anyway, so there's no need to run the GC to clean up reference cycles.
It's a total waste of effort.

> 3.
> import foo
> def __del__(self, foo=foo):
>   foo.bar()
>
> What happens here to prevent a NameError? Apparently without the foo=foo
> a NameError can occur? But why? import foo creates a reference to the
> object anyways so it's refcount will be above 0 anyways till __del__ is
> called.

I'm not sure where you're trying to put that code. If you put that at
module level, __del__ won't get called, because there's nothing
special about that name in a module.

During interpreter shutdown, modules will get unloaded, and stuff in
modules will get unloaded. But I'm not even going to _start_
explaining exactly what happens, until I know where this is heading;
there's almost certainly a better way to do this. What is it you're
actually trying to accomplish?

> 4. also, are method calls more efficient than function calls?

No. They in fact *are* function calls, but with a slight bit of magic
so they get their first parameter passed in. You can consider them to
be identical to function calls.

ChrisA