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: zope3-users@zope.org
> > 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
> > Zope3-users@zope.org
> > http://mail.zope.org/mailman/listinfo/zope3-users
>
>
>
> _______________________________________________
> Zope3-users mailing list
> Zope3-users@zope.org
> http://mail.zope.org/mailman/listinfo/zope3-users
>


--
Jeff Shell
_______________________________________________
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users

Reply via email to