[Zope] overload __getattr__ in brains-class?
Fri, 19 Jul 2002 21:14:46 +0200
Jo Meder writes:
> The standard procedure for simulating class attributes in Python I
> normally use is (set discussions of efficiency aside for a moment):
> class a:
> def __init__(self):
> self.realattrib_a="this is real"
> def __getattr__(self,key):
> if key in self.__dict__.keys():
> return self.__dict__[key]
> return "simulated attribute"
You do not need the "then" part!
"__getattr__" is only called when the normal lookup fails.
This includes the lookup in "self.__dict__", any subclass
and (in Zope) the acquisition context.
> Now I take this definition and use it as my brain-class.
> And to my astonishment this already barfs on
> '<dtml-with expr="result">' with a traceback
> telling me that the __init__ of class a is flawed since there is no
> attribute "realattrib_a".
> ??? How can an __init__-method complain about nonexisting attributes
> when all I'm trying to do is define some?
That's a restriction (bug) of the "Result" class.
It is implemented in "C" as an ExtensionClass without "__dict__".
Therefore, you cannot assign any (new) attributes to its instances:
the set of attributes is fixed to the set of result columns.
All derived classes inherit this property (they do not have a
I think, it is a bug. I reported it in the mailing list and
in the (old) collector. It could probably easily be changed
(whether or not an Extension Class has a __dict__ or not is controlled
by a flag in the corresponding type).
But it's implemented in "C" and in order to use the modification,
one needs a "C" development systems. Many Zope users do not have
one. That's why I more hesitant to provide patches for "C" parts
than for Python parts.