[Python-Dev] Smart resource destruction (was Re: Use for enumerate) (original) (raw)

Ian Kjos ikjos@email.uophx.edu
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.

** As demonstrated by the loop-savvy garbage collection upgrade, for example.

*** .class et. al. notwithstanding. The point is to avoid, for example, circular linked lists.

----- Original Message ----- From: "Barry A. Warsaw" <barry@zope.com>

Here's a 5 minute toy example...

-Barry [big code block....]