[Baypiggies] On Python Design

[Alex Martelli]

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!

Alex


On Wed, Mar 5, 2008 at 3:28 PM, Glen Jarvis <glen at glenjarvis.com> wrote:
>
>
> 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
>
>
> _______________________________________________
>  Baypiggies mailing list
>  Baypiggies at python.org
>  To change your subscription options or unsubscribe:
>  http://mail.python.org/mailman/listinfo/baypiggies
>