[Zope3-dev] Re: [Zope3-checkins] CVS: Zope3/lib/python/Zope/ContextWrapper/tests - testSimpleMethodWrapper.py:1.8

[Steve Alexander]

Jeremy Hylton wrote:
> "SA" == Steve Alexander <steve@cat-box.net> writes:
> 
> 
>   SA> + def __getitem__(wrapped_self, a, b=None):
>   SA> + wrapped_self.result = wrapped_self, a, b
>   SA> + return a
>   SA> + __getitem__ = ContextMethod(__getitem__)
>   SA> +
>   SA>      def thisIsNotAContextMethod(self, val=None):
>   SA>          self.result = self return val
>   SA> @@ -69,6 +74,11 @@
>   SA>          return a
>   SA>      __call__ = ContextMethod(__call__)
> 
> This code deserves some decent variable names and maybe a comment or
> two.

Why? It is a unit test for testing the handling of non-contextmethods 
and contextmethods in various different kinds of classes. If you read 
the tests, the uses of the classes being tested should be apparrent.

Obviously, it is not apparrent from the diffs in the checkin.


> What are a and b?

Arbitrary values passed to __call__. __call__ puts them in an instance 
variable, which is inspected by the unit-test to see if __call__ got 
called appropriately.


> __getitem__() only takes one argument, so I don't
> get the optional argument.

Some people might use obj.__getitem__(several, arguments). I don't want 
that to break when it is as easy to ensure it works.


> We better explain that the reason we need an __getitem__ defined this
> way is because __getattribute__ isn't invoked for __getitem__ when it
> is accessed from C through the sequence or mapping API.

That is explained (for __call__) on the documentation wiki. I didn't get 
time to update that with __getitem__ yet, but I will. I've been pretty 
good about maintaining this documentation :-)

You can find the docs by typing in "contextmethod" into the search box 
on http://dev.zope.org

http://www.zope.org//Wikis/DevSite/Projects/ComponentArchitecture/Zope.ContextWrapper.ContextMethod



> And what's that business about wrapped_self.result?  That seems like
> it needs a comment, too.

I don't think so. We're allowing the unit-test to check exactly what the 
__getitem__ of the class received. This is a unit test. We're testing 
the units.


> I'm also wondering what we're going to do about all the other __
> methods -- __setitem__, __delitem__, __len__, __iter__, __contains__.
> I'm not sure which of these are mapped to slots in the type object,
> but I'll bet a bunch of them are.

We don't need those at the moment, because no-one has had the 
requirement to use the 'acquisition' context from those methods.


Part of the good refactoring is to reimplement the SimpleMethodWrapper 
classes in C, and automatically generate the appropriate combinations 
from a template.

It is a good job we had the python implementation, though, because the 
exact way the method rebinding works has had to change a couple of 
times, as we discovered things about how it should work.

--
Steve Alexander