Resource cleanup

[Robin Becker]

I'm thinking of using Tim Peters' excellent approach to resource clean
up see

http://mail.python.org/pipermail/pyt...il/063425.html

class _RealTypeResourceCleaner:
def __init__(self, *resources):
self.resources = resources

def __del__(self):
if self.resources is not None:
for r in self.resources:
r.close()
self.resources = None

# and typically no other methods are needed, or desirable, in
# this helper class

class RealType:
def __init__(*args):
...
# and then, e.g.,
self.cleaner = _ResourceCleaner(resource1, resource2)

but am wondering exactly what 'resources' are left available when the
r.close method is called in the __del__ method of RealTypeResourceCleaner.

In particular, can I rely on the module globals of r still being present
if the RealType instance is going away because the main script has
terminated, ie if the r.close method refers to a global function is it
guaranteed to be available when the close is called?

I guess I must be asking if referring to a global in a method is
actually a reference to that global or does the reference only occur
when the code is executed?

I have a vague feeling that I came across problems in the past about the
order in which modules were finalized.
--
Robin Becker

[Diez B. Roggisch]

but am wondering exactly what 'resources' are left available when the

r.close method is called in the __del__ method of RealTypeResourceCleaner.

In particular, can I rely on the module globals of r still being present
if the RealType instance is going away because the main script has
terminated, ie if the r.close method refers to a global function is it
guaranteed to be available when the close is called?

I guess I must be asking if referring to a global in a method is
actually a reference to that global or does the reference only occur
when the code is executed?

I have a vague feeling that I came across problems in the past about the
order in which modules were finalized.

I'm a bit on unsure ground here - so take it with a grain of salt.

It is for sure that only executing code will refer to a global - the
mere mention of anything can't possibly create a reference (in python at
least) - consider this simple example:

import random

def foo():
print schroedingers_cat

if random.random() .5:
schroedingers_cat = "I'm alive!"

foo()
So I presume it can very well happen that you will lose a module when
trying to finalize.

So most probably it is the cleverest solution to make the cleaner as
self-contained as possible, by storing explicit references to things you
might need in the instance itself. But I'm not sure if the transitivity
of dependencies might not kick your ass somewhere anyhow.

All in all an interesting topic - I'd be looking forward to more
insights, and very much liked the link you gave us.
Diez

[Robin Becker]

Diez B. Roggisch wrote:
........

>>
I have a vague feeling that I came across problems in the past about
the order in which modules were finalized.

I'm a bit on unsure ground here - so take it with a grain of salt.

It is for sure that only executing code will refer to a global - the
mere mention of anything can't possibly create a reference (in python at
least) - consider this simple example:

import random

def foo():
print schroedingers_cat

if random.random() .5:
schroedingers_cat = "I'm alive!"

foo()

yes I guess although foo must know that schroedingers_cat is global it
doesn't need to bring it into existence so would fail 50% of the time :)

>
So I presume it can very well happen that you will lose a module when
trying to finalize.

So most probably it is the cleverest solution to make the cleaner as
self-contained as possible, by storing explicit references to things you
might need in the instance itself. But I'm not sure if the transitivity
of dependencies might not kick your ass somewhere anyhow.

I think this must be the right approach. Either the resources or the
cleaner should hold everything required for cleanup. Probably the
resource is the best place.

--
Robin Becker