In article <[EMAIL PROTECTED]>, "Paul McGuire" <[EMAIL PROTECTED]> wrote:
> "Carl Banks" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > > 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 -- http://mail.python.org/mailman/listinfo/python-list
