[TransWarp] component path - property name dualism, does this make sense?

Phillip J. Eby pje at telecommunity.com
Wed Aug 20 09:36:50 EDT 2003


At 12:24 PM 8/20/03 +0200, Matthias Drochner wrote:

>pje at telecommunity.com said:
> > Okay, one more try...  make the 'propertyMap' binding be
> > 'activateUponAssembly=True', and have the __getattr__ check 'if
> > self._hasBinding('propertyMap'):'
>
>This causes an infinite recursion for me...
>
> > By the way, you don't have any components that are overriding __init__ or
> > that might be trying to get access to these attributes before they
> > themselves know their parent, do you?
>
>Not that I know of... One thing which happens with current CVS
>is an attribute lookup of __conform__.

Okay...  I found the problems.  Basically, the problem is that propertyMap 
and __getattr__ were both too "promiscuous" in returning attributes for 
anything.

The minimum fix is to set the propertyMap binding to 'suggestParent=False', 
i.e.:

propertyMap = binding.Once(propertyMap, activateUponAssembly=True, 
suggestParent=False)

The problem here was that it would try to suggest parents for the 
propertyMap, and the return value of propertyMap has a promiscuous 
__getattr__ that causes problems here.  (I may take that out later, it 
seems to me that we aren't actually *using* that feature of propertysets.)

The second fix, that is not required to get your test to run, but which I 
suggest anyway, is to make the __getattr__ of the ConfigDelegate class 
always raise AttributeError if the attr.startswith('_').  This should 
prevent any accidental __getattr__ leakage for things that aren't desired 
configuration values.

Based on the debugging I did, I'm beginning to wonder if maybe 
'suggestParent' should *default* to False.  Although it is very convenient 
in the general case, it tends to lead to weird results when it's not the 
right setting.  Conversely, if one were required to set it to true, the 
errors occuring from failing to do so would probably be easier to debug.

Hm.  Actually, it's probably that binding.Once() (and maybe 
binding.Constant()) should default to suggestParent=False, since a Once 
routine has plenty of opportunity to set its return value's parent.  I'll 
have to look over our usage in PEAK to make a determination, though.




More information about the PEAK mailing list