does python have useless destructors?

[Donn Cave]

Quoth Carl Banks <imbosol at aerojockey.invalid>:
...
| These are silly examples, of course, but with more intricate stuff (or
| with code by other people who are always less disciplined than you)
| this can become a real problem.  Face it, people, it's ludicrous to
| rely on the garbage collector to finalize stuff for us.

`Face it?'  We're not the ones talking about preposterous hypothetical
cases and hand-waving claims about intricate code written by people
who don't know what they're doing.  There's boatloads of Python code
with constructs like the text = open(file, 'r').read() usage proposed
in this thread, and it's truly no problem.  If you want to make that
into a laborious exercise in defensive programming, that's your problem.

It is a fact that there are some issues that have to be understood for
more general use of finalization, but that's part of understanding
Python's storage model.  That model is in the end no simpler or more
intuitive than any other language - really worse than most - but it's
functional.  At the cost of occasionally baffling the newcomer, it lets
us write modular code that doesn't impose on the caller to manage objects.
I don't need to know whether my function is the sole user of an object
and it falls to me to free it when I'm done, because the system takes
care of that.  I get it, I use it, I forget about it.  I realized what
a huge architectural difference that makes when I tried to translate a
non-trivial program to C.  If the choice is either to abandon that
advantage for resources other than (small chunks of) memory, or learn
how to deal with the tricky corner cases, I'll take the latter.

	Donn Cave, donn at drizzle.com