[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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
