atexit functionality

[Chad Netzer]

On Wed, 2003-04-09 at 12:15, viszneki at telerama.com wrote:
>  Gee I'm such a jerk.

Relax.  Let it slide.

> 
> If anyone has anything positive to say about my idea, please say so.

I think Duncan's suggestion about maintaining your own list, was a very
good one.

>  In my last 
> email to this mailing list, I posted some hypothetical code to do the job:
> 
> return _exithandlers[len(_exithandlers)]

This will fail by definition, since indexing begins at 0.  You probably
meant:

return _exithandlers[len(_exithandlers) - 1]

or

return _exithandlers[-1]


> Shortly after having sent it, I realized it wouldn't work because of the way 
> Python does things

Hence, Duncan's suggestion, and use of the remove() method of lists.

However, my view is that if you have objects that can "cleaned up"
before their reference count goes to zero (ie. other things can still
refer to it, and potentially call its methods), then you have a design
problem and need to reconsider what you want.  Or you want to make use
of existing facilities that Python already provides (see below).

> I tried this myself, by adding that line of code to the end of 
> atexit.register, just to make sure, because I am admittedly no master at 
> pointer dynamics in Python (something I wish I knew more about.)

Well, first, don't think in terms of "pointers".  Objects all have
lifetimes based on references, which are just a name to refer to an
object.  You can decide to eliminate a reference to an object, but you
can't (generally) decide to destroy an object at any specific time
unless you know you control all the references to an object (ie, such as
lists, dictionaries, etc.)

With regards to your cleanup idea, if you want to allow people to call
cleanup() functions, and thus free up and invalidate object resources,
before the lifetime of the object is ended (ie. being able to close
files or remove references to other objects), then you should generally
protect your member functions from using those freed up resources after
the cleanup has occured.  This could be done by having a "cleanedup" or
"invalid" flag on the object, which is set True when an early cleanup
has occurred.  this could be a lot of extra work, for little gain,
however.

Perhaps you should investigate the "weakref" standard module, which
gives you a way to refer to another object without increasing it's
reference count (and thus potentially preventing it from "cleaning up"
when it otherwise could.)  So, you could hand out references to an
object, and still allow it to be cleaned up only after all non-weak
references have been dropped (ie. avoiding early cleanup).  Users of
weakrefs will generally be forced to always check the reference before
using it anyway, which formalizes the usage I outlined above.


> Thank you everybody for your time,
> Donny Viszneki.

-- 
Bay Area Python Interest Group - http://www.baypiggies.net/

Chad Netzer
(any opinion expressed is my own and not NASA's or my employer's)