When (and why) to use del?

[Albert Hopkins]

I'm looking at a person's code and I see a lot of stuff like this:

def myfunction():
# do some stuff stuff
my_string = function_that_returns_string()
# do some stuff with my_string
del my_string
# do some other stuff
return

and also

def otherfunction():
try:
# some stuff
except SomeException, e:
# more stuff
del e
return


I think this looks ugly, but also does it not hurt performance by
preempting the gc? My feeling is that this is a misuse of 'del'. Am I
wrong? Is there any advantage of doing the above?

 

[Slaunger]

I'm looking at a person's code and I see a lot of stuff like this:

        def myfunction():
            # do some stuff stuff
            my_string = function_that_returns_string()
            # do some stuff with my_string
            del my_string
            # do some other stuff
            return

and also

        def otherfunction():
            try:
                # some stuff
            except SomeException, e:
                # more stuff
                del e
            return

I think this looks ugly, but also does it not hurt performance by
preempting the gc?  My feeling is that this is a misuse of 'del'. Am I
wrong?  Is there any advantage of doing the above?

I agree with you. In my mind there is no reason for such kinds of
deletes. The code seems to have been made by a person who úsually
programs in a language which does not have a garbage collector. I do
not know if it has any noticeable impact on the performance.

-- Slaunger

 

[malkarouri]

I'm looking at a person's code and I see a lot of stuff like this:

        def myfunction():
            # do some stuff stuff
            my_string = function_that_returns_string()
            # do some stuff with my_string
            del my_string
            # do some other stuff
            return

and also

        def otherfunction():
            try:
                # some stuff
            except SomeException, e:
                # more stuff
                del e
            return

I think this looks ugly, but also does it not hurt performance by
preempting the gc?  My feeling is that this is a misuse of 'del'. Am I
wrong?  Is there any advantage of doing the above?

As far as I understand it, this does not do anything. Let me explain.
The del statement doesn't actually free memory. It just removes the
binding from the corresponding namespace. So in your first example,
my_string cannot be used after the deletion. Of course, if the string
referenced by my_string was referenced by some other name then it will
still stay in memory.

In both your examples, the bindings are going to be removed anyway
immediately after the del statement, when returning from the function.
So, the del is redundant. If for some reason, however, you are not
breaking your work into functions (not advisable) you will have a huge
list of commands with no deletion and start to use huge amounts of
memory. Solution: divide your work into functions.

It is sometimes, however, useful to preempt the gc. This can be done
when you know that this is a good time to do chores, e.g. on an
application's idle period. Calling gc.collect() is useful here.

Regards,

Muhammad Alkarouri

 

[pruebauno]

I'm looking at a person's code and I see a lot of stuff like this:

        def myfunction():
            # do some stuff stuff
            my_string = function_that_returns_string()
            # do some stuff with my_string
            del my_string
            # do some other stuff
            return

and also

        def otherfunction():
            try:
                # some stuff
            except SomeException, e:
                # more stuff
                del e
            return

I think this looks ugly, but also does it not hurt performance by
preempting the gc?  My feeling is that this is a misuse of 'del'. Am I
wrong?  Is there any advantage of doing the above?

If this is CPython (the standard Python) the extra del(s) in the
examples you gave are just garbage and good for nothing. The reason
being that they are inside a function; as soon as the program exits
the function the variable gets deleted automatically. The only reason
to use del would be a global variable in long running program that
uses a lot of space, but global variables should be avoided for other
reasons anyway. I never ever used del in my programs only on the
interactive interpreter prompt after doing foolish things like x=open
('1GBfile').read()

 

[Bruno Desthuilliers]

malkarouri a écrit :
(snip)

The del statement doesn't actually free memory. It just removes the
binding from the corresponding namespace. So in your first example,
my_string cannot be used after the deletion. Of course, if the string
referenced by my_string was referenced by some other name then it will
still stay in memory.

And even if it wasn't, and as such ends up being garbage-collected, this
doesn't mean the allocated memory will go back to the system.

(snip)

 

[rdmurray]

It is probably a complete waste of time, but there are situations where
code similar to this can be useful:

def otherfunction():
try:
# some stuff
except SomeException, e:
# more stuff
del e
raise
return

The point of code like this is that when a function exits by throwing an
exception the traceback includes a reference to the stack frame and all the
local variables. In some situations that can result in large data
structures not being freed for a very long time (e.g. until another
exception is thrown that is handled at the same level). So, *in very
specialised situations* it may be important to delete particular names from
the local namespace.

If I'm reading http://www.python.org/dev/peps/pep-3110/ right, Python
3.0 eliminates even this use case

I have had occasions to use del, when I don't want the variable in the
namespace anymore for some reason (for example, when I'm later going to
be scanning the namespace for some reason).

--RDM