[Zope-dev] How to override __getattr__ and not break acquisition

[John Barratt]

Casey Duncan wrote:
> __getattr__ hooks are evil, only to be used as a last resort. Are you So I've found, and heard!  It didn't stop me from tyring, and I still don't see why they should be so hard so work with, difficult perhaps, but I wouldn't have though you needed to pull the seemingly impossible to have them work (with zope at least)!

>creating some sort of transparent proxy object? What exactly are you 
>trying to do? I'm not getting a big picture here. And why do you need 
See my last post (I posted it before I saw this one sorry), but
basically I want a link/reference type functionality that hooks in
before containment acquisition, and I think I've worked it out another
way to do it as per that post.

>to call the inherited __getattr__ from Implicit? Doesn't raising an 
>AttributeError take care of this?
Yes it does, but it wasn't so simple in this case (This is where the
'evil' you mentioned earlier comes in).  Part of my problem was the need
to call another class method on self which in turn needs to access a
method on self that comes from containment acquisition on self, which
would call my overridden __getattr__ and have an exception rasied due to
not doing containment acquisition.  This exeption would then be caught
in the code calling the first __getattr__ call, and not the second.  Can
python not handle exceptions properly with recursive function calls, or
was this my bad analysis and/or just being generally confused?

> > One other way that may work is to be able to set methods on the object
> > as it comes out of the ZODB for use, as I need to be able to get methods
> > from other objects in the ZODB, something to explore... Anyone have any
> > pointers on this one perhaps?
> 
> Yes, but that would change the attributes and cause the ZODB to save 
>them on commit (unless you use volatile '_v_' attrs). This might not be 
>a bad thing.
I might be able to use _v_ attrs, otherwise the storing bit would be
very bad unless the store method was also overriden and they were
deleted on the way out.

Thanks,

JB.