Chris Withers wrote:
Michel Pelletier wrote:
Python Methods are a perfect example of an object that is useful to us at the top for advanced things, like methods of a animal base class we use in our complex Zoo application, but they are also just as useful to those at the bottom, as a simple little script written in python that feeds the hippos. Or unobfusicates their DTML. Or iterates over a database query. It's useful and saves the time of these novice Zope users if these methods can be flexible and reusable in different contexts. To me, this is the heart of the container vs. context binding argument. We at the top ususaly want the container because we're engineering methods on classes. Those at the bottom usually want context for entirely different reasons. Evan has done a great job making an object that satisfies the entire spectrum, but in the process has come up with something that is not entirely unlike a method in python.
...this clears things up a lot. So, a python x can be bound to containment _or_ context depending on how it's setup, right?
Sorta. There is a bindings tab on PythonMethods where you assign names to various variables that show up in your namespace. 'self' is the container. 'context' is the context. So: self.objectValues() will allways call the container whereas: context.objectValues() will call the method on the currently bound object.
I say leave it to the vote, although I liked that complex voting algorithm thing someone posted, it sounds like it'd leave more people happier.
Unfortunately, complex also means "too hard for me to think too hard about". Any volunteers? -Michel