Python 2.0

[Tim Peters]

>[Salvador]
> I have been using Java since it was invented and I haven't programed a
> finaliser ever. They should run under so unknown and inconsistent
> environment that they are not usable at all (except for freeing external
> resources).

[Graham Matthews]
> I am not sure I understand this. Can you explain to me how a finaliser
> can run in an unknown environment. Surely everything the finaliser needs
> is referenced by the finaliser (either directly or indirectly) and hence
> is still there.

The caveats are explained well in the Java Language Spec, section 12.6.  In
short, you can't know which thread a finalizer will run in; you can't be
sure that an object is unreachable at the time its finalizer is invoked; you
can't know *when* a finalizer will be invoked; even if it is unreachable at
the time its finalizer is invoked, you can't be sure that it won't become
reachable again *after* the finalizer returns; and in the case of cyclic
object structures nothing is specified about the order in which the objects'
finalizers will be called (indeed, they may all run simultaneously).

All Java defines is enough so that the Java runtime itself never chokes on
e.g. an internal null pointer, i.e., your "still there" guarantee.  Say you
have a mail server holding a ref to a mail client, which in turn holds a ref
back to the mail server.  Can the client object tell the server it's going
away at finalization time?  Not if the server object shut down the
communications link beforehand because the server's finalizer happened to
get called first.  Etc.  Yes, the references are "still there", but without
a lot of pain there's no guarantee they're still in a *useful* state.

"Therefore, we recommend that the design of finalize methods be kept simple
and that they be programmed defensively, so that they will work in all
cases."

good-advice-in-any-language-ly y'rs  - tim