[Python-Dev] Smart resource destruction (was Re: Use for enumerate)
Sun, 28 Apr 2002 04:23:39 -0500
Look, if we're so careful about thread-naive code not crashing the
interpretter (*) or circular references leaking memory (**), then I don't
see why naive code should be allowed to leak file descriptors, database
handles, query buffers, locks, or other similar things which:
1. Are implemented as and provided by C code.
2. Do not contain references to other python objects. (***)
3. Refer to computational resources outside the program's memory.
It's not about providing one-shot methods. Clearly better is a function that
does everything in one go. What I'm trying to communicate is that knowledge
of what (should) happen when a file's notional refcount hits zero should be
embedded in the file object, not each bit of code lucky enough to be the
last place said file object is used. The same goes for other purely external
resources. Basically, we should put things away when we are done with them.
The more the language supports the programmer in doing that, the more
productive I think she'll be. I also realize that the real resource is the
os-level file descriptor, not the language-level file object. (That's more
an implementation thing, though.)
Now the first character who wants to subclass file() will surely make this
scheme all fall apart. I can't think of why to do such a thing, but that
doesn't mean some genius (ahem) out there won't. Clearly there are issues.
Nobody wants a solution tomorrow. Sometime before Python 3.0 might be nice,
but is totally not necessary either.
* It doesn't appear possible to write non-thread-naive code in python, or at
least not without changing the whole model of computation, which is a black
hole that I don't want to think about. That's just as well, though.
** As demonstrated by the loop-savvy garbage collection upgrade, for
*** .__class__ et. al. notwithstanding. The point is to avoid, for example,
circular linked lists.
----- Original Message -----
From: "Barry A. Warsaw" <firstname.lastname@example.org>
> Here's a 5 minute toy example...
> [big code block....]