threading support in python
steve at holdenweb.com
Wed Sep 6 09:52:34 CEST 2006
sjdevnull at yahoo.com wrote:
> Paul Rubin wrote:
>>Jean-Paul Calderone <exarkun at divmod.com> writes:
>>>>which more explicitly shows the semantics actually desired. Not that
>>>>"huge" a benefit as far as I can tell. Lisp programmers have gotten
>>>>along fine without it for 40+ years...
>>>Uh yea. No lisp programmer has ever written a with-* function... ever.
>>The context was Lisp programmers have gotten along fine without
>>counting on the refcounting GC semantics that sjdevnull advocates
>>Python stay with. GC is supposed to make it look like every object
>>stays around forever, and any finalizer that causes an explicit
>>internal state change in an extant object (like closing a file or
>>socket) is not in the GC spirit to begin with.
> I disagree, strongly. If you want "every object stays around forever"
> semantics, you can just not free anything. GC is actually supposed to
> free things that are unreachable at least when memory becomes tight,
> and nearly every useful garbage collected language allows destructors
> that could have effects visible to the rest of the program. Reference
> counting allows more deterministic semantics that can eliminate
> repeating scope information multiple times.
Clearly you guys are determined to disagree. It seemed obvious to me
that Paul's reference to making it "look like every object stays around
forever" doesn't exclude their being garbage-collected once the program
no longer contains any reference to them.
You simplify the problems involved with GC-triggered destructors to the
point of triviality. There are exceedingly subtle and difficult issues
here: read some of the posts to the python-dev list about such issues
and then see if you still feel the same way.
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden
More information about the Python-list