[Zope] overload __getattr__ in brains-class?

[Dieter Maurer]

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]
 > 		else:
 > 			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[0]">' 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
"__dict__").

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.


Dieter