Is that not a standard problem in the Zope context?
If you access any object via acquisition or the DTML namespace, then the definition of a new property can break code: the property may be retrieved rather than an object formerly acquired, looked up deeper in the namespace.
Yes. Both of these mechanisms can only be made robust by controlling which namespace will staisfy namespace search. That means not relying on the fact that a name will not be found in an 'uncontrolled' namespace. I posted a patch on this list a while back, which used a __getattr__ hook to list all the names which were being looked up, but not found, in the zope root object. The output is listed at http://www.zope.org/Members/htrd/names. Try creating a property under one of those names and see what breaks. (this list was created with 2.2.x. several patches to fix such issues have been merged since then) There are several solutions to this problem: for dtml, switch to a different language for any non-trivial logic. for acquisition, 2.3.0 introduced a __replaceable__ attribute that adds protection to a name inside a containment heirarchy. This is a good start, but not yet a total solution.