[packagekit] yum2 backend

[Robin Norwood]

On Fri, 15 Feb 2008 11:23:19 -0500
Owen Taylor <otaylor at redhat.com> wrote:

> 
> On Fri, 2008-02-15 at 16:26 +0100, Patryk Zawadzki wrote:
> > On Fri, Feb 15, 2008 at 3:58 PM, Robin Norwood
> > <rnorwood at redhat.com> wrote:
> > > On Fri, 15 Feb 2008 14:30:53 +0100
> > >  Tim Lauridsen <tim.lauridsen at googlemail.com> wrote:
> > >
> > >  > I spend some time make the yum2 dbus backend work.
> > >  >
> > >  > Had to comment out all dbus service methods in the base class
> > >  > (deamonBackend.py) because it looks like overloading the
> > >  > methods in yumDBUSBackend.py was not working, so when calling
> > >  > the methods from
> > >
> > >  Thanks for fixing that up...I thought it was working for me the
> > > other night, but tests in the harsh light of day show that it
> > > doesn't work for me now either. Any python guys know anything
> > > about overloading decorators, and why this wouldn't be working?
> > 
> > A decorator is an immediately evaluted function. It is evaluated at
> > declaration time, not at instance creation time. If it does some
> > magic tricks like passing the decorated method to an external
> > library, it does the magic on the exact method that it prepends.
> > Also:
> > 
> > @foo
> > def bar:
> >     pass
> > 
> > is equal to:
> > 
> > def bar:
> >     pass
> > bar = foo(bar)
> > 
> > So you really overload the decorator's output, not the original
> > method.
> 
> If you look at dbus.server.method annotation implementation:
> 
>  @dbus.service.method(in_signature='i', out_signature='i', ...)
>  def bar(self, some_int):
>      return int 
> 
> Is basically equivalent to:
> 
>  def bar(self, some_int):
>      return int 
>  bar._dbus_in_signature='i'
>  bar._dbus_out_signature='i'
>  ...
> 
> [...] 
> 
> So the real question is "how are the _dbus_<blah> properties on the
> class's methods being used?".
> 
> If we then look at how DBUS-Python implements method lookup, it's by
> a a function that is documented as:
> 
> def _method_lookup(self, method_name, dbus_interface):
>     """Walks the Python MRO of the given class to find the method to
> invoke.
> 
>     Returns two methods, the one to call, and the one it inherits
> from which defines  its D-Bus interface name, signature, and
> attributes. """
> 
> So, the fact that the base class method is the one with the properties
> should not matter. And I just tried a quick test and it confirmed
> what I deduced from the code: it works fine to:
> 
>  - Annotate a method in a base class
>  - Override in a child class without annotations
> 
> So, it's really not clear to me why there would be problems here. 

Hrm.  I had both sets of methods annotated, with is probably what
broke.  I don't particularly like the idea of having the set in the
base class annotated, and the one in the actual class not.  Just too
magical.  So I'll probably leave things the way they are, since it
Works.

-RN

-- 
Robin Norwood
Red Hat, Inc.

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching