[Python-Dev] Getting rid of unbound methods: patch available
Guido van Rossum
gvanrossum at gmail.com
Tue Jan 18 18:32:49 CET 2005
[me]
> > 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?
[Marc-Andre]
> 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
> cease to work since it uses this attribute to figure out
> the class object defining the overriding method.
Well, you could always do what Timothy Delaney's autosuper recipe
does: crawl the class structure starting from object.__class__ until
you find the requested method. Since you're using a cache the extra
cost should be minimal.
I realize that this requires you to issue a new release of mxTools to
support this, but you probably want to do one anyway to support other
2.5 features.
> 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 :-)
Easy. There is a lot of code in the instance method type specifically
to support the case where im_self is NULL. All that code can be
deleted (once built-in exceptions stop using it).
> 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.
Isn't mxProxy a weak referencing scheme? Is it still useful given
Python's own support for weak references?
> I would expect code in the following areas to make use
> of the type check:
> * language interface code (e.g. Java, .NET bridges)
Java doesn't have the concept of unbound methods, so I doubt it's
useful there. Remember that as far as how you call it, the unbound
method has no advantages over the function!
> * security code that tries to implement object access control
Security code should handle plain functions just as well as (un)bound
methods anyway.
> * RPC applications that use introspection to generate
> interface definitions (e.g. WSDL service definitions)
Why would those care about unbound methods?
> * debugging tools (e.g. IDEs)
Hopefuly those will use the filename + line number information in the
function object. Remember, by the time the function is called, the
(un)bound method object is unavailable.
> >>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 ?
Yes, by the built-in exception code. (It surprised me too; I think in
modern days it would have been done using a custom descriptor.)
BTW, decorators and other descriptors are one reason why approaches
that insist on im_class being there will have a diminishing value in
the future.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev
mailing list