Nick:

1. Yes, the code actually patches an unrelated regression too
(DB.verify() crashes). I added the testcase, since the testsuite didn't
exercise "DB.verify()" and so the bug was lurking there for months. It
is solved now, and the testcase is there to protect us in the future.

I can split the patch, if demanded, nevertheless.

2. About commenting "do_not_close" use, I agree. Done. Now the code says:

"""
        /*
        ** "do_not_close" is used to dispose all related objects in the
        ** tree, without actually releasing the "root" object.
        ** This is done, for example, because function calls like
        ** "DB.verify()" implicitly close the underlying handle. So
        ** the handle doesn't need to be closed, but related objects
        ** must be cleaned up.
        */
"""

Similarly in "DBSequence.remove()".

I'm actually thinking about splitting "*_close_internal()" functions in
"release related objects"+"object close". I don't like the
"do_not_close" flag. But that would be a post-2.6.0 change that I'm
still considering.

3. About "dummy=DB_close_internal(*) + Py_XDECREF", the crashes are
related to raising exceptions *while* deallocating objects. These are
solved with this patch.

Other "dummy=DB_close_internal(*) + Py_XDECREF" uses need be improved,
but they do not crash the library, and the changes are a bit extensive
for a post RC code. They are in my TO DO list, but I think they can be
left out of Python 2.6.0. See my previous post.

4. I agree with you. The problem is related to cleaning a
partially/incorrectly initialized object. Ideally the error should be
raised in the object constructor. Nevertheless in this case the RPC
initialization involves several functions that must be called in
sequence: object created as "RPC enabled"+specifying the details of
remote RPC server. If the handle is disposed before the second step, it
can be safely deallocated without showing any spurious error. In this
concrete example, I don't think the user needs to know about the
"phantom" error.

If you don't agree, please tell to me. Would be a few "fprintf()" enough?.

Thanks for your time, Nick.