Maybe the Zope-Dev guys have comments on this....
From: Jim Fulton <jim@digicool.com>
Michel,
You have advocated that methods should always be bound to the objects they are accessed in. You argue that there should be no choice in the matter.
I have to disagree strongly. I'll try to explain why.
In Python, methods are bound to instances. Methods are part of an instance's core behavior. They are specific to the kind of thing the instance is. In my words, methods are part of the genetic makeup of an object.
In Zope, we allow some methods to be bound to their context. This is done in a number of ways and is sometimes very useful. We have methods, like standard_html_header, which are designed to be used in different contexts.
We have other methods, like manage_edit that are designed to work on specific instances. It would be an egregious error if this method was acquired and applied to it's context.
We have some methods that are designed to bound to an instance (container, in your terminology) but that, because they are written in DTML, can be bound to other objects. This can cause significant problems. For example, methods defined in ZClasses almost always want to be bound to ZClass instances, not to other arbitrary objects.
<aside>There's a bonus problem with DTML Methods. When a DTML Method is invoked from another DTML Method, it is bound to neither the object it was accessed in or to the object it came from. It is bound to the calling namespace. It turns out that this is a useful behavior if the DTML Method is designed to be used as a "subtemplate". </aside>
There is no one "right" way to bind a method. There are good reasons to sometimes bind a method to it's context and sometimes bind a method to it's container (ie instance). There are even sometimes reasons to bind a method to a calling namespace.
The principle of least surprise doesn't help here, because methods defined in Python classes don't behave the way methods defined through the web do currently.
We *need* control over binding, as well as reasonable defaults.
If we can agree that we need binding control, the question arises as to some details and default names.
Should it be possible to do more than one binding at a time, using multiple names? If not, then I'd agree that the name 'self' should be used for either the context or container binding. If both bindings are allowed at the same time, then 'self' should refer to container binding to be consistent with standard Python usage and some name like 'context' should be used (by default) for contextual binding.
Jim