Article of interest: Python pros/cons for the enterprise

Carl Banks pavlovevidence at gmail.com
Mon Feb 25 07:19:51 EST 2008


On Feb 24, 7:03 pm, a... at pythoncraft.com (Aahz) wrote:
> In article <Y9KdnVYb7bq_m13anZ2dnUVZ_sedn... at comcast.com>,
> Jeff Schwab  <j... at schwabcenter.com> wrote:
> >(3) Garbage collection is at least as desirable a language feature as
> >deterministic destruction.
>
> Enh.  There probably are some people who claim that, but I can't think
> of any off-hand.

I am most certainly claiming it; in fact I'm claiming that GC far more
desirable, because the cost of deterministic destruction is too high.

The costs are:
1. extra effort (which Jeff Schwab denied but I don't remotely buy it)
2. mistakes are easier to make and more catastrophic when made

With deterministic destruction, you have to worry about the lifetime
of every single object, and that requires effort.

Either you are literally keeping track of all the object and manually
freeing and deleting them like in C, or you are sticking to a rigid
disciplined style that (mostly) guards against practices that lead to
invalid pointers and memory leaks.  The discipline itself takes
effort, but the rigid style also limits expressiveness, often
severely, and so you have to expend more effort writing the same
thing.

Point is, one way or another, you are paying for deterministic
destruction with more effort.

Even that innocuous object on the local stack frame can bite you if
you pass it to a function that, expecting a heap object, stores a
pointer.  Which means you have to keep track of what the functions
you're calling do, and you have to be deliberate about what the
functions you're writing do, so still more effort, yadda yadda.

I don't really think I have to say much with regard to error-proneness
compared to GC, nor the cost of mistakes  Invalid pointer dereferences
and segfaults don't happen in Python (aside from extensions), and
memory leaks only happen when you accidentally keep objects alive.
Mistakes are far more common and dangerous in C++.

And subtle I might add.  A destroyed object that is improperly
derferenced might "work" for awhile since its memory hadn't been
overwritten, then suddenly crash and burn in slightly different
circumstances (such as if it's running a different computer, like, for
instance, the customer's).

And tracking down and fixing those bugs, compared to the sorts of bugs
you get from garbage collection?  You guessed it--more effort.

Deterministic destruction would be a great thing if it weren't for all
the drawbacks.  Until then I will choose the path of lesser effort by
letting GC take care of memory, closing my own files, and having lots
of expressive power and freedom.


Carl Banks



More information about the Python-list mailing list