RetroSearch Browse

Tue Jan 18 10:28:57 CET 2005 · http://mail.python.org/pipermail/python-dev/2005-January/051172.html

Guido van Rossum wrote:
> [Guido]
> 
>>>Apart from the tests that were testing the behavior of im_class, I
>>>found only a single piece of code in the standard library that used
>>>im_class of an unbound method object (the clever test in the pyclbr
>>>test). Uses of im_self and im_func were more widespread. Given the
>>>level of cleverness in the pyclbr test (and the fact that I wrote it
>>>myself) I'm not worried about widespread use of im_class on unbound
>>>methods.
> 
> 
> [Marc-Andre]
> 
>>I guess this depends on how you define widespread use. I'm using
>>this feature a lot via the basemethod() function in mxTools for
>>calling the base method of an overridden method in mixin classes
>>(basemethod() predates super() and unlike the latter works for
>>old-style classes).
> 
> 
> I'm not sure I understand how basemethod is supposed to work; I can't
> find docs for it using Google (only three hits for the query mxTools
> basemethod). How does it depend on im_class?

It uses im_class to find the class defining the (unbound) method:

def basemethod(object,method=None):

     """ Return the unbound method that is defined *after* method in the
         inheritance order of object with the same name as method
         (usually called base method or overridden method).

         object can be an instance, class or bound method. method, if
         given, may be a bound or unbound method. If it is not given,
         object must be bound method.

         Note: Unbound methods must be called with an instance as first
         argument.

         The function uses a cache to speed up processing. Changes done
         to the class structure after the first hit will not be noticed
         by the function.

     """
     ...

This is how it is used in mixin classes to call the base
method of the overridden method in the inheritance tree (of
old-style classes):

class RequestListboxMixin:

     def __init__(self,name,viewname,viewdb,context=None,use_clipboard=0,
                  size=None,width=None,monospaced=1,events=None):

         # Call base method
         mx.Tools.basemethod(self, RequestListboxMixin.__init__)\
                            (self,name,size,width,monospaced,None,events)

         ...

Without .im_class for the unbound method, basemethod would
seize to work since it uses this attribute to figure out
the class object defining the overriding method.

I can send you the code if you don't have egenix-mx-base
installed somewhere (its in mx/Tools/Tools.py).

>>What I don't understand in your reasoning is that you are talking
>>about making an unbound method look more like a function.
> 
> That's a strange interpretation. I'm getting rid of the unbound method
> object altogether.

Well, you do have to assign some other type to the object
that is returned by "myClass.myMethod" and as I understood
your proposal, the returned object should be of the
FunctionType. So from an application point of view, you
are changing the type of an object.

>>Unbound
>>methods and bound methods are objects of the same type -
>>the method object.
> 
> Yeah I know that. :-)
> 
> And it is one of the problems -- the two uses are quite distinct and
> yet it's the same object, which is confusing.

Hmm, I have a hard time seeing how you can get rid
off unbound methods while keeping bound methods - since
both are the same type :-)

>>By turning an unbound method into a function
>>type, you break code that tests for MethodType in Python
>>or does a PyMethod_Check() at C level.
> 
> 
> My expectation  is that there is very little code like that. Almost
> all the code that I found doing that in the core Python code (none in
> C BTW) was in the test suite.

I'm using PyMethod_Check() in mxProxy to automatically
wrap methods of proxied object in order to prevent references
to the object class or the object itself to slip by the
proxy. Changing the type to function object and placing
the class information into a function attribute would break
this approach. Apart from that the type change (by itself)
would not affect the eGenix code base.

I would expect code in the following areas to make use
of the type check:
* language interface code (e.g. Java, .NET bridges)
* security code that tries to implement object access control
* RPC applications that use introspection to generate
   interface definitions (e.g. WSDL service definitions)
* debugging tools (e.g. IDEs)

Perhaps a few others could scan their code base as well ?!

>>If you want to make methods look more like functions,
>>the method object should become a subclass of the function
>>object (function + added im_* attributes).
> 
> Can't do that, since the (un)bound method object supports binding
> other callables besides functions.

Is this feature used anywhere ?

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 10 2005)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2005-January/051172.html below:

[Python-Dev] Getting rid of unbound methods: patch available