[Baypiggies] On Python Design

[Glen Jarvis]

PUT DOWN THE CRACK PIPE LOUISE!!!    I'm an idiot...

Alex, I didn't actually understand your message before I sent a reply.  
Of course! You're right... in the __init__ of the "cool" object, I can  
call the atexit.register() function AFTER I instantiate the  
monitoring....

This way, the exit will occur only in the parent process.

You can disregard my previous email because obviously I was obviously  
high on stupid when I wrote it.

Your solution, as simple as it is, just wasn't coming to me. I was  
getting suddenly confused and, more importantly, worried, that I'd  
boxed myself in the corner. This was so easy.

I'm on BART, waiting until I can get to embaracadero so I can send  
this...  Is it Friday yet? =)

Thanks again for all of your help...



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


On Mar 5, 2008, at 4:23 PM, Alex Martelli wrote:

> I should clarify what I mean, apparently: you can just call
> atexit.register from the __init__ of the "cool" object AFTER you
> instantiate the monitor object, since in the parent process does that
> initialization return to the caller.
>
> On Wed, Mar 5, 2008 at 4:13 PM, Glen Jarvis <glen at glenjarvis.com>  
> wrote:
>> Alex,
>>    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.
>
> OO vs modules really has nothing to do with it.  Each forked process
> should see to its own termination cleanup (if any) by calling
> appropriate atexit.register.
>
>> I believed Object Orientation was a very nice way to approach this.
>
> I disagree -- initializing a class exactly once and having its only
> instance "just go away immediately" makes not much sense to me when
> one can simply call a function instead -- the kind of thing one ends
> up doing in a language that "forces" OO design, like Java, not
> appropriate in a multiparadigm language allowing both objects and
> functions, like C++ or Python.  But, that's not really connected to
> the atexit/fork issue, one way or another.
>
>> However, it is no longer feeling so clean. It's starting to look
>> "Ugly" to use Guido speak...
>>
>> Does this help explain my concerns?
>
> Not really -- why not do the obvious thing (ensuring atexit.register
> is only called in the parent process after the fork)?
>
>
> Alex