fork()

[Evan Simpson]

Tim Peters wrote in message <000b01beb6ef$fcaba960$069e2299 at tim>...
> So my plan for the hour <wink> is:  if M&S finds a cycle, it will clean it
> all up iff no involved object has a __del__.  If an object in a trash
cycle
> does have a __del__, tough, the cycle won't be reclaimed.  Instead we'll
> supply a function you can call if you care, that will return those objects
> (one at a time?  in a list?  whatever), and you do with them what you
will;
> if you don't clean them up, you'll keep getting them back every time you
> call that function until you resurrect them or break the cycle by hand in
> the way that makes most sense to your algorithm.

Presuming the hour isn't up yet, I've a handful of scattered comments:

. How about a callback instead of/in addition to a probe function?  That way
you could flip a switch and get called even on cycles which are "del-clean",
if you wanted to check for unintentional cycle creation.
. "del-cleanness" only requires that actual cycle participants lack __del__,
not dangly bits, right?  Or does this re-introduce analysis that you
intended to throw out?
. (somewhat rhetorical) How the heck do you recognize what you've got when
the machinery hands you an object which isn't otherwise reachable?  I
realize that there's no general answer to this, and that in some specific
cases it would be enough to check __bases__, but the only answer which
occurs to me off the bat is to uniquely mark objects which you expect to
have to handle, or provide them with special __cleanup__ methods, or the
like.  Now we have wide-open policy, which I recall you decrying <wink>.  I
guess that no matter what mechanism is implemented, certain badly-handled
cases will appear and need to be handled with "well, don't do that!"

finalization-is-like-life-you-can't-win-and-you-can't-break-even-ly y'rs
Evan Simpson