[Baypiggies] On Python Design

[Glen Jarvis]

At BayPIGgies, I get a lot of help learning the language, good coding  
standards, etc… But, I hadn’t seen much on good architecture/design,  
tips/tricks, etc. Maybe we can add a future talk on  architecture  
ideas/concepts to our list?

Before that day, however, I’m desperate to get some help with  
something that I designed (I thought well), only to find myself boxed  
in a corner.

My project is obviously something I can’t discuss in too much detail  
(although I think it's silly, I promised not to share; and I always  
try to keep my promises). So, I made a sample test case to demonstrate  
a hypothetical situation that mimics my situation.

I have a self monitoring API that launches behind the scenes for the  
developers that use such a job. It is called simply by importing the  
library and instantiating an object. For example:

import time
import DaCoolAPI

# This is kewl
myDaCool = DaCoolAPI.DaCool()

print "Ho hum.. working away..."
for x in range(1, 5):
     print ".",
     time.sleep(1.0)

But, behind the scenes, as soon as DaCoolAPI is instantiated, config  
files are parsed, external processes for monitoring are launched, etc.

The problem is I had intended the entire time to do things, like clean- 
up, when the DaCool object was ‘done’ (i.e., almost always at program  
exit).

In this test case, the DaCool.__del__ destructor is called without  
worry. However, that is NOT a guarantee in the big picture (my much  
larger app). Now, trying to get the Python atexit module (http://docs.python.org/lib/module-atexit.html 
) to do this same job is tricker than it looks.

Everything has previously been at the object level. The atexit is a  
module level function. I don’t readily have access to the objects I  
need at the module level. And, most of my clean-up are hidden within  
objects. Also, if I do this in the monitoring portion, I’m obviously  
going to get multiple processes all seeing the atexit function and get  
the exit handlers called two or three times.

*gasp*

When I thought I was using a clean object oriented design, I suddenly  
have a mess because I didn’t know destructors were never guaranteed to  
run….


*breath*

Now, with all of that said, I would like to ask my questions:

1)       1) Have I over-used the object-oriented model?
2)       2) Is there a clean fix to get this back into the object- 
oriented model?
3)       3) Do I need to change all objects so they are modules  
(although that isn’t possible for at least one – the one that needs to  
be provided for the programmer)


Any feedback, ideas, input – even pickiness if I missed some coding  
standards – are all appreciated. It never hurts to tear this to pieces  
– The gems I get are worth any bruises to my ego - and I get to learn  
something from those mistakes so I'm a better coder next time =)


Cheers,


Glen
  --
415-680-3964
glen at glenjarvis.com
http://www.glenjarvis.com

"You must be the change you wish to see in the world." -M. Gandhi


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/baypiggies/attachments/20080305/6a1a314f/attachment-0002.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DaCoolAPI.py
Type: text/x-python-script
Size: 1115 bytes
Desc: not available
Url : http://mail.python.org/pipermail/baypiggies/attachments/20080305/6a1a314f/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DaCoolMonit.py
Type: text/x-python-script
Size: 2674 bytes
Desc: not available
Url : http://mail.python.org/pipermail/baypiggies/attachments/20080305/6a1a314f/attachment-0003.bin 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/baypiggies/attachments/20080305/6a1a314f/attachment-0003.htm