RFC: Proposal: Deterministic Object Destruction

[ooomzay at gmail.com]

On Friday, March 2, 2018 at 10:43:57 PM UTC, Steven D'Aprano wrote:
> On Fri, 02 Mar 2018 07:09:19 -0800, ooomzay wrote:
> [...]
> >> If you're going to *require* the programmer to explicitly del the
> >> reference:
> >>
> >>     f = open("file")
> >>     text = f.read()
> >>     del f
> > 
> > But I am not! On the contrary RAII frees the programmer from even having
> > to remember to close the file. The poster asked what would happen if the
> > resource was deliberately kept open by storing a reference at global
> > scope.
> 
> You say that as if it were difficult to do, requiring the programmer to 
> take extraordinary steps of heroic proportion. It doesn't.
> It is unbelievably easy to store the reference at global scope, which 
> means that the programmer needs to remember to close the file explicitly 
> and RAII doesn't help.

Can you expand on what you mean by "unbelievably easy to store the reference 
at global scope". I will assume you are claiming that it is easy to 
_inadvertently_ store a global reference. Can you give an example of how 
this might happen? (Apart from writing leaky exception handlers, which I 
trust no one thinks is a good idea)

> [...]
> Your justification for requiring RAII is to ensure the timely closure of 
> resources -- but to do that, you have to explicitly close or delete the 
> resource. It simply isn't true that "RAII frees the programmer from even 
> having to remember to close the file".

In the special case (keyword global) that you reference resources from global 
scope - then yes, you must remember to del the global references before you 
exit to avoid relying on the vagaries of exit processing.

This problem with destruction of globals on exit is not unique to python. 
There are patterns to manage this for code you control, such as putting them 
all in one global "bucket" object and explicitly deleting it before exit.

> >> then you might as well require them to explicitly close the file:
> >> 
> >>     f = open("file")
> >>     text = f.read()
> >>     f.close()
> >> 
> >> which we know from many years experience is not satisfactory except for
> >> the simplest scripts that don't need to care about resource management.
> >> That's the fatal flaw in RAII:
> > 
> > We must be discussing a different RAII. That is the raison d'etre of
> > RAII: RAII directly addresses this problem in an exception-safe way that
> > does not burden the resource user at all.
> 
> But as you said yourself, if the resource is held open in a global 
> reference, it will stay open indefinitely. And remember, global in this 
> context doesn't just mean the main module of your application, but 
> *every* module you import.

Can you give an example of such a case where an application-managed 
(acquired/opened & released/closed) resource is referenced strongly by 
a 3rd party module at global scope? ...in my experience this pattern 
usually smells.

> I think you have just put your finger on the difference between what RAII 
> *claims* to do and what it *actually* can do.

I can assure you that RAII does what it says on the tin and is relied on in 
many critical systems to release resources robustly ... given the 
pre-requisite deterministic destruction.