One could, but it's really not worth it. It's just the laws of Python and mutability and immutability :). (It took me years to understand those terms. I kept associating them with 'mutable' in the "can be made quiet" sense... Eventually my music brain stepped back and I went "oh, MUTATE! Ahhh!". Seriously, it took me about four years to understand that :).
Anyways, it comes down to this. They're just different statements: >>> compiler.parse("a.b = [1,2,3]") Module(None, Stmt([Assign([AssAttr(Name('a'), 'b', 'OP_ASSIGN')], List([Const(1), Const(2), Const(3)]))])) >>> compiler.parse("a.b.extend([1,2,3])") Module(None, Stmt([Discard(CallFunc(Getattr(Getattr(Name('a'), 'b'), 'extend'), [List([Const(1), Const(2), Const(3)])], None, None))])) It's just easier to set the dirty bit yourself or use the persistent object (or use the trick to re-assign after modifying). Personally, I seldom store lists, or even use them as attributes on instances. Even outside of Zope/ZODB, I've found myself accidentally losing data because I was carelessly using the reference. Tuples for everybody! On 2/15/06, Shaun Cutts <[EMAIL PROTECTED]> wrote: > Well, one could have a base class along the lines of > > class PersistSetItemOnAttributes: > > def __setattr__( self, attr, val ): > oldSI = val.__class__.__dict__.get( '__setitem__', None ) > if oldSI is not None: > def newSI( vself, vattr, vval ): > vself._p_changed = True # is this the right member? > oldSI( vattr, vval ) # oldSI is bound: no vself? > val.__class__.__setitem__ = newSI > super( PersistSetItemOnAttributes, self ).__setattr__( attr, val > ) > > Of course, this is really just pseudocode. For one thing, need to trap > whether 'val' is really a class. For another if you were serious about > this, you would want to check if the obj wasn't persistent first, and > you might want to do it recursively. And while your are at it, you might > want to check on other mutators as well....(for instance, check first > what sequence interface if any 'val' supports...) > > ... sounds like too much work, and would be problem prone even so. After > all, some things you don't want to be persistent! > > - Shaun > > > -----Original Message----- > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > > On Behalf Of Stephan Richter > > Sent: Wednesday, February 15, 2006 8:43 AM > > To: email@example.com > > Cc: Florian Lindner > > Subject: Re: [Zope3-Users] What attributes are made persistent > > > > On Wednesday 15 February 2006 08:21, Peter Bengtsson wrote: > > > class PersistentAnything(PersistentMapping, PersistentList, > > > PersistentDict): > > > > AAhhhh! This is so wrong! It merges two incompatible APIs: collections > and > > mappings. The non-persistent equivalent to this is: > > > > >>> class DoEverything(set, list, dict): > > ... pass > > > > > Am I just trying to make it too simple? > > > > I think you try far too hard to not understand why the persistent > > mechanism > > works as it does. You make your life harder than it has to be. > > > > Regards, > > Stephan > > -- > > Stephan Richter > > CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) > > Web2k - Web Software Design, Development and Training > > _______________________________________________ > > Zope3-users mailing list > > Zope3firstname.lastname@example.org > > http://mail.zope.org/mailman/listinfo/zope3-users > > > > _______________________________________________ > Zope3-users mailing list > Zope3email@example.com > http://mail.zope.org/mailman/listinfo/zope3-users > -- Jeff Shell _______________________________________________ Zope3-users mailing list Zope3firstname.lastname@example.org http://mail.zope.org/mailman/listinfo/zope3-users