A question on decorators

[castironpi at gmail.com]

On Mar 26, 6:02 pm, "Gabriel Genellina" <gagsl-... at yahoo.com.ar>
wrote:
> En Wed, 26 Mar 2008 18:01:31 -0300, George Sakkis  
> <george.sak... at gmail.com> escribió:
>
> > On Mar 26, 3:41 pm, Tim Henderson <tim.t... at gmail.com> wrote:
>
> >> I am using mysql, and sqlite is not appropriate for my situation since
> >> some of the databases and tables I access are being accessed by other
> >> applications which are already written and live. I am not using the
> >> SQLAlchemy or SQLObject, because I didn't want too (although in the
> >> future I may consider using them).
>
> > I'd strongly second looking into SQLAlchemy; from what you wrote, I
> > suspect sooner or later you'll end up creating (to paraphrase
> > Greenspun) an ad hoc, informally-specified, bug-ridden, slow
> > implementation of half of SQLAlchemy.
>
> You beat me to say that, but using SQLObject instead.
> Moreover, the OP is looking for the PersistentDict and PersistentList  
> classes that ZODB uses.
> I'm not sure that triggering a database write for each and every modified  
> attribute is a good thing; I'd use a "dirty" flag instead (ZODB uses  
> _p_changed) and write all modifications at the end.
> Since not all methods modify the object contents, using a metaclass to  
> flag all of them isn't a good idea either. I'd use a decorator; after all,  
> they're not so many methods; if you inherit from DictMixin you only have  
> to write __getitem__, __setitem__, __delitem__ and keys(), and of those,  
> only __setitem__ and __delitem__ modify the object.

That depends on technology: in volatile memory, persistence is a long-
term commitment.  In static-state memory, it's a norm.  Say you've got
a flash drive on the bus, you could store the objects themselves: the
Python module would have to allocate from the ROM, reobtain later.
Don't store the interpreter on the ROM, and trade-off feature sets for
expiration date.  But standards expire?