[Patches] Safe destruction of recursive objects

[Guido van Rossum]

> > > > +   Unfortunately, deallocations also take place when
> > > > +   the thread state is undefined.
> 
> Ok, you said you were about to check this in when
> you read my comment concerning thread state.
> But I don't see these things to be related. The patch
> works fine. Is there anything besides lack of time, keeping you from
> checking this in? Do you expect more input from me?

I am worried about the possibility of this code being run without the
interpreter lock held -- it allocates a list and calls
PyList_Append(), it's not safe to do this when another thread could be
doing the same thing.  PyList_New() is thread-safe, but
PyList_Append() to a list reachable via a global is not!

Should I worry?

Other comments on the patch (which I didn't have the time to review
earlier):

- Can we avoid creating new little files for every little feature?
This stuff should go into object.{c,h}.

- Your _PyTrash_deposit_object(op) doesn't check for errors from
PyList_New() and PyList_Append().  Typically, destructors shouldn't do
anything that could cause an exception to be raised, because
destructors may be called while an existing exception is being
handled.  You'd have to wrap your code in PyErr_Fetch() and
_Restore(), like classobject.c does when it calls __del__ from a
deallocator.

- Please submit the append compatibility patch separately.

--Guido van Rossum (home page: http://www.python.org/~guido/)