Antwan Reijnen writes:
... accessing properties with "getProperty" and "propertyItems".... Agree, but consider this: when I retrieve a fixed set of data, on propertysheets with varying number of properties (N), the fetchprocedure takes more time when N increases... Why should propertysheet.getProperty('aProperty') take longer on a larger propertysheet?
Currently, PropertySheets store their properties directly as attributes of the parent (i.e. the ZClass instance). Because of this, "getProperty" cannot relay on an "AttributeError" to see that "id" is really a property. It, therefore, calls "hasProperty" and then uses "getattr" on the parent. Properties have not been conceived as a mass storage concept. Therefore, the properties description is stored as a tuple. "hasProperty" iterates over the tuple and checks for the "id". This is linear in the size of the tuple. With current Zope, your most efficient way to access a property is "getattr" on the ZClass instance. Of course, this requires that you know what you access is really a property of the object. If not, you may get an acquired non-property. The PropertySheet implementers have been aware that the current storage mechanism (abusing the parent for storage) is a break in the PropertySheet's concept (different PropertySheets should provide separate namespaces; currently, they are couple by the parents namespace). Therefore, they documented that accessing properties via "getattr" from the parent may be removed in future versions. Personally, I do not expect this to happen, as it will break almost all ZClass applications. There may be new PropertySheets in Zope 3, that do it differently. But, for backward compatibility, the current sheets will almost surely continue to work as you see now. Dieter