[Python-Dev] Design question: call __del__ for cyclical garbage?

[Tim Peters]

[Tim sez "toss insane cycles back on the user"]

[Greg Stein]
> I disagree. I don't think a Python-level function is going to have a very
> good idea of what to do.

You've already assumed that Python coders know exactly what to do, else they
couldn't have coded the new __clean__ method your proposal relies on.  I'm
taking what strikes me as the best part of Scheme's Guardian idea:  don't
assume *anything* about what users "should" do to clean up their trash.
Leave it up to them:  their problem, their solution.  I think finalizers in
trash cycles should be so rare in well-written code that it's just not worth
adding much of anything in the implementation to cater to it.

> IMO, this kind of semantics belong down in the interpreter with a
> specific, documented algorithm. Throwing it out to Python won't help
> -- that function will still have to use a "standard pattern" for getting
> the cyclical objects to toss themselves.

They can use any pattern they want, and if the pattern doesn't *need* to be
coded in C as part of the implementation, it shouldn't be.

> I think that standard pattern should be a language definition.

I distrust our ability to foresee everything users may need over the next 10
years:  how can we know today that the first std pattern you dreamed up off
the top of your head is the best approach to an unbounded number of problems
we haven't yet seen a one of <wink>?

> Without a standard pattern, then you're saying the application will know
> what to do, but that is kind of weird -- what happens when an unexpected
> cycle arrives?

With the hypothetical gc.get_cycle() function I mentioned before, they
should inspect objects in the list they get back, and if they find they
don't know what to do with them, they can still do anything <wink> they
want.  Examples include raising an exception, dialing my home pager at 3am
to insist I come in to look at it, or simply let the list go away (at which
point the objects in the list will again become a trash cycle containing a
finalizer).

If several distinct third-party modules get into this act, I *can* see where
it could become a mess.  That's why Scheme "guardians" is plural:  a given
module could register its "problem objects" in advance with a specific
guardian of its own, and query only that guardian later for things ready to
die.  This probably can't be implemented in Python, though, without support
for weak references (or lots of brittle assumptions about specific refcount
values).

agreeably-disagreeing-ly y'rs  - tim