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