30

I tend to use it whenever I am working on a prototype script, and:

  1. Use a somewhat common variable (such as fileCount), and
  2. Have a large method (20+ lines), and
  3. Do not use classes or namespaces yet.

In this situation, in order to avoid potential variable clash, I delete the bugger as soon as I am done with it. I know, in a production code I should avoid 1., 2., and 3., but going from a prototype that works to a completely polished class is time consuming. Sometimes I might want to settle for a sub-optimal, quick refactoring job. In that case I find keeping the del statements handy. Am I developing an unnecessary, bad habit? Is del totally avoidable? When would it be a good thing?

Mogsdad
  • 44,709
  • 21
  • 151
  • 275
Hamish Grubijan
  • 10,562
  • 23
  • 99
  • 147
  • 1
    I agree that it can be useful. I know I’ve been bitten by a loop variable leaking and then being set when it shouldn’t be. – Josh Lee Dec 24 '10 at 21:37
  • 1
    "Is del totally avoidable?" -> You only need it for `del mydict[key]` etc – Jochen Ritzel Dec 24 '10 at 22:15
  • Using del needlessly defeats the purpose of having memory management. You're already paying for it - why not use it. – nate c Dec 24 '10 at 22:23
  • 1
    @nate c, (at least my) concern is not performance, but rather reusing a variable (due to a typo/poor code organization) that spilled from a for loop and/or a previous block of code with a wrong value in it. Copy-and-paste type of code is particularly prone to errors ;) – Hamish Grubijan Dec 24 '10 at 23:28
  • 1
    It defeats the purpose by adding unnecessary logic to something that is already done for you. Name collisions are a bug in any language (with or without memory management) and can be solved through other means. – nate c Dec 25 '10 at 00:15
  • @nate c Even with GC, it's still useful if you're working with objects so large that they took up most of the available memory, and you can't keep more than one alive at once. If you don't del it, the GC won't be able to free it until the end of the function at which point you've already crashed. – Antimony Oct 03 '12 at 03:29
  • 2
    Related: [When is del useful in python?](http://stackoverflow.com/q/6146963/95735) – Piotr Dobrogost Feb 17 '13 at 19:06

2 Answers2

26

I don't think that del by itself is a code smell.

Reusing a variable name in the same namespace is definitely a code smell as is not using classes and other namespaces where appropriate. So using del to facilitate that sort of thing is a code smell.

The only really appropriate use of del that I can think of off the top of my head is breaking cyclic references which are often a code smell as well (and often times, this isn't even necessary). Remember, all del does is delete the reference to the object and not the object itself. That will be taken care of by either reference counting or garbage collecting.

>>> a = [1, 2]
>>> b = a
>>> del a
>>> a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined
>>> b
[1, 2]

You can see that the list is kept alive after the del statement because b still holds a reference to it.

So, while del isn't really a code smell, it can be associated with things that are.

stalepretzel
  • 15,543
  • 22
  • 76
  • 91
aaronasterling
  • 68,820
  • 20
  • 127
  • 125
  • 1
    __del does is delete the reference to the object__ it's not totally true , what __del__ do is decrement the reference counter by 1 of the variable and remove the binding variable name from the namespace. – mouad Dec 24 '10 at 21:48
  • 14
    Deleting a reference to an object _means_ removing it from a namespace and decrementing the reference counter. That is if the Python implementation uses reference counting. If it doesn't, `del` does the former but not the latter. – Rosh Oxymoron Dec 24 '10 at 21:50
  • 1
    ok yes, maybe i didn't understand it well :), don't mind me +1; – mouad Dec 24 '10 at 21:54
9

Any code that's well organized in functions, classes and methods doesn't need del except in exceptional circumstances. Aim to build your apps well factored from the start by using more functions and methods, avoid reusing variable names, etc.

The use of a del statement is OK - it doesn't lead to any trouble, I use it often when I use Python as a replacement for shell scripts on my system, and when I'm making script experiments. However, if it appears often in a real application or library, it is an indication that something isn't all right, probably badly structured code. I never had to use it in an application, and you'd rarely see it used anywhere on code that's been released.

Rosh Oxymoron
  • 20,355
  • 6
  • 41
  • 43
  • I don't even use it in scripts... my scripts don't get that long ;) –  Dec 24 '10 at 21:44
  • @delnan, scripts can quickly grow longer if you include reasonable error checking. If these scripts are for your [debugging] eyes only - fine. If your script depends on the output of some other script or a build process, I think it is wise to anticipate changes to that output format and bail out with a useful error message as soon as you discover it. – Hamish Grubijan Dec 24 '10 at 22:00
  • @Hamish: Yes, but that's more `if` and `print` statements, not more variables. –  Dec 24 '10 at 23:23
  • 3
    It's still useful for deleting stuff from dicts. – Antimony Oct 03 '12 at 03:30