threading support in python
Steve Holden
steve at holdenweb.com
Wed Sep 6 03:52:34 EDT 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.
regards
Steve
--
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
mailing list