[Python-Dev] Finalizers considered questionable ;) (original) (raw)

Jim Fulton jim@digicool.com
Wed, 15 Mar 2000 08:35:48 -0500

• Previous message: [Python-Dev] unicode objects and C++
• Next message: [Python-Dev] Finalizers considered questionable ;)
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Here's my $0.02.

I agree with the sentiments that use of finalizers should be discouraged. They are extremely helpful in cases like tempfile.TemporaryFileWrapper, so I think that they should be supported. I do think that the language should not promise a high level of service.

Some observations:

• I spent a little bit of time on the ANSI Smalltalk committee, where I naively advocated adding finalizers to the language. I was resoundingly told no. :)

• Most of the Python objects I deal with these days are persistent. Their lifetimes are a lot more complicated that most Python objects. They get created once, but they get loaded into and out of memory many times. In fact, they can be in memory many times simultaneously. :) A couple of years ago I realized that it only made sense to call init when an object was first created, not when it is subsequently (re)loaded into memory. This led to a change in Python pickling semantics and the deprecation of the loathsome getinitargs protocol. :)

  For me, a similar case can be made against use of del for persistent objects. For persistent objects, a del method should only be used for cleaning up the most volatile of resources. A persistent object del should not perform any semantically meaningful operations because del has no semantic meaning.

• Zope has a few uses of del. These are all for non-persistent objects. Interesting, in grepping for del, I found a lot of cases where del was used and then commented out. Finalizers seem to be the sort of thing that people want initially and then get over.

I'm inclined to essentially keep the current rules and simply not promise that del will be able to run correctly. That is, Python should call del and ignore exceptions raised (or provide some optional logging or other debugging facility). There is no reason for del to fail unless it depends on cyclicly-related objects, which should be viewed as a design mistake.

OTOH, del should never fail because module globals go away. IMO, the current circular references involving module globals are unnecessary, but that's a different topic. ;)

Jim

-- Jim Fulton mailto:jim@digicool.com Python Powered!
Technical Director (888) 344-4332 http://www.python.org
Digital Creations http://www.digicool.com http://www.zope.org

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of 500damages/incident,500 damages/incident, 500damages/incident,1500 for repeats.

• Previous message: [Python-Dev] unicode objects and C++
• Next message: [Python-Dev] Finalizers considered questionable ;)
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]