Is there a reason not to do this?

[Ron Garret]

In article <z3Obh.10535$Gk5.800 at tornado.texas.rr.com>,
 "Paul McGuire" <ptmcg at austin.rr._bogus_.com> wrote:

> "Carl Banks" <pavlovevidence at gmail.com> wrote in message 
> news:1164942311.945476.147100 at f1g2000cwa.googlegroups.com...
> >
> > A straightforward, Pythonic way to do it would be to create an
> > intermediate representation that understands both the existing class
> > interfaces and the RDB stuff, but that could lead to synchronizing
> > problems and a big hit in performance.  And it's probably a lot of work
> > compared to tacking on methods.  OTOH, it could help with hairiness you
> > mention.  (I recently did something similar in one of my projects,
> > though the intermediary was transient.)
> >
> I would second Carl's recommendation that you find some way to persist an 
> interim version of these expensive-to-create objects, so you can quickly 
> load debuggable instances to accelerate your development process.  With 
> luck, you can get by with out-of-the-box marshal/unmarshal using the pickle 
> module.  We've done this several times in my office with objects that an 
> application creates only after some extensive GUI interaction - it just 
> slows down development too much without some quick import of debuggable 
> instances.
> 
> Even though this seems like a sidetrack, it's a pretty direct shortcut, 
> without too much unusual technology or design work.

These objects can be parts of huge networks of massively linked data 
structures.  They are in constant flux.  It is not uncommon to hit a bug 
after many minutes, sometimes hours, of computation.  Having to store 
the whole shlemobble after every operation would slow things down by 
orders of magnitude.  And writing code to be clever and only store the 
dirty bits would be a pain in the ass.  I think I'll stick with Plan A.

rg