[Baypiggies] On Python Design
glen at glenjarvis.com
Thu Mar 6 01:13:27 CET 2008
I'm sorry this isn't coming across clearly, let me try this again
- but shorter (and hopefully more clear).
The API attached in the previous email forks two processes. This means
three total processes are running at any one time. If we register the
self.close() function, it will be executed three times (once for each
process). I can avoid some of this by how I exit: (os._exit(1))
instead of sys.exit.
I can also make a 'NormalExit' function, and re-register it at the
times that processes are spawned, but this solution is not very
elegant. In fact, it feels like I'm hacking to get this to work
(although I believe I could).
So, my over-all question is about the design approach. What have you
(or another reading this message) come across when mixing Object
Orientation, modules, atexit, and forked processes.
I believed Object Orientation was a very nice way to approach this.
However, it is no longer feeling so clean. It's starting to look
"Ugly" to use Guido speak...
Does this help explain my concerns?
P.S. Executing the program with attached files as an API may also help
clear up some of the confusion. However, the output is very messy
since it comes from three processes all at once.
glen at glenjarvis.com
"You must be the change you wish to see in the world." -M. Gandhi
On Mar 5, 2008, at 3:58 PM, Alex Martelli wrote:
> I'd just rename __del__ to close, and add an
> atexit.register(self.close) to the __init__ -- i.e., the "one obvious
> way" to ensure that some termination is performed at program exit by
> calling at that time an appropriate method on an object. If there are
> constraints that stop you from pursuing this solution, I apologize but
> I can't parse them from your mail, so please clarify -- thanks!
> On Wed, Mar 5, 2008 at 3:28 PM, Glen Jarvis <glen at glenjarvis.com>
>> 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 ".",
>> 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
>> when the DaCool object was 'done' (i.e., almost always at program
>> In this test case, the DaCool.__del__ destructor is called without
>> However, that is NOT a guarantee in the big picture (my much larger
>> Now, trying to get the Python atexit module
>> (http://docs.python.org/lib/module-atexit.html) to do this same job
>> tricker than it looks.
>> Everything has previously been at the object level. The atexit is a
>> 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
>> processes all seeing the atexit function and get the exit handlers
>> two or three times.
>> 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….
>> 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-
>> 3) 3) Do I need to change all objects so they are modules
>> 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
>> from those mistakes so I'm a better coder next time =)
>> Glen --
>> glen at glenjarvis.com
>> "You must be the change you wish to see in the world." -M. Gandhi
>> Baypiggies mailing list
>> Baypiggies at python.org
>> To change your subscription options or unsubscribe:
More information about the Baypiggies