[Zope] Wrapping objects: __getattr__ weirdness

[Paul Winkler]

Update for anyone interested... 

if there were explorer's maps for zope product hackers,
it would say "here be dragons" where __getattr__ and
__bobo_traverse__ are.  Not for the faint of heart.

actually __bobo_traverse__ seems pretty sensible as
long as you don't get too ambitious :)

I spent some time fiddling with __getattr__ as described
previously, then following advice from SteveA on #zope I 
switched to overriding __bobo_traverse__.  that was
equally confusing - it worked ok with wrapping DTML *sometimes*
(but not for /index_html for some reason), but didn't
work with zpt and I couldn't figure why.

spent much time in #zope trying to figure it out - eventually
someone (zopezen?) said "another sacrifice at the altar of the mythical
symlink product" and I threw in the towel.
somebody else said "there's a reason the mythical symlink product
is mythical." :-\   There were also hints that this kind
of thing might be easier in zope3.

Instead I'm going to programatically copy and paste my shared
content to its destinations as part of my workflow.
there will still be some ugly issues with getting it to
fit in properly in all the contexts I need to handle, but
I don't think it could possibly get as weird as working
with __getattr__ and __bobo_traverse__.


On Wed, Oct 09, 2002 at 05:33:04PM -0700, Paul Winkler wrote:
> I'm trying to write a pretty transparent wrapper product in 
> python, which will have one property, source_path,
> which contains a (string) path to another object.
> I can resolve this path to the object, no problem;
> but I cant' see how to delegate attribute requests
> to it. my  __getattr__ fails with  
> (snip - complete traceback later):
(snip)

--

Paul Winkler
"Welcome to Muppet Labs, where the future is made - today!"