Martin Aspeli wrote at 2007-1-9 20:48 +0000:
>>> - It's an explicit declaration of support
>> As is the definition of "__of__".
>Well, not in a formal sense. I could have some non-Zope python object
>that I wanted to register as a local utility (to override a global one,
>say) that could have __of__() for some other reason.
Theoretically, you might be right -- but not practically
in the "ExtensionClass" based environment of Zope 2.
There you have: if an object has an "__of__" it is used
for context wrapping -- as soon at it happens to be accessed
as attribute of an "ExtensionClass" instance.
In this environment, it is more homogenous and natural to just wrap
with "__of__" when it is present than looking for an additional
>I doubt it matters in this case (I'd guess __of__() is not a very common
>method name outside Zope, and this would be pretty localised code)...
More precisely, "__of__" has special (documented) meaning for "ExtensionClass".
>>> - It may not be desirable to wrap everything that *could* be wrapped.
>What if the method wasn't __of__() but get_size() or something in a
I think, I would not have argued about automatic "get_size" wrapping --
unless it were so common as "ExtensionClass"'s "__of__" wrapping.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See http://collector.zope.org/CMF for bug reports and feature requests