Bind the instance argument of a descriptor method to the calling object instance

Question

In a descriptor, the second argument to __get__ and __set__ is bound to the calling object instance (and the third argument to __get__ is bound to the calling owner class object):

class Desc():
    def __get__(self,instance,owner): 
        print("I was called by",str(instance),"and am owned by",str(owner))
        return self

class Test():
    desc = Desc()

t = Test()
t.desc

How would I go about creating a decorator to bind the second argument of another descriptor method (other than __get__, __set__, or __delete__) to the instance object?

Example (just an example; not something I'm actually trying to do):

class Length(object):
    '''Descriptor used to manage a basic unit system for length'''
    conversion = {'inches':1,'centimeters':2.54,'feet':1/12,'meters':2.54/100}
    def __set__(self,instance,length):
        '''length argument is a tuple of (magnitude,unit)'''
        instance.__value = length[0]
        instance.__units = length[1]
    def __get__(self,instance,owner):
        return self
    @MagicalDecoratorOfTruth
    def get_in(self, instance, unit): #second argument is bound to instance object
        '''Returns the value converted to the requested units'''
        return instance.__value * (self.conversion[units] / self.conversion[instance.__units])

class Circle(object):
    diameter = Length()
    def __init__(self,diameter,units):
        Circle.diameter.__set__((diameter,units))

c = Circle(12,'inches')
assert c.diameter.get_in('feet') == 1
c.diameter = (1,'meters')
assert c.diameter.get_in('centimeters') == 100

One way I have considered trying is wrapping the get_in method with a decorator. Something similar is done using the @classmethod decorator, where the first argument of a class method is bound to the class object instead of the class instance object:

class Test():
    @classmethod
    def myclassmethod(klass):
        pass

t = Test()
t.myclassmethod()

However, I'm unsure how to apply this to the case above.

A way to avoid the whole problem would be to pass the instance object to the descriptor method explicitly:

c = Circle(12,'inches')
assert c.diameter.get_in(c,'feet') == 1
c.diameter = (1,'meters')
assert c.diameter.get_in(c,'centimeters') == 100

However, this seems to violate D.R.Y., and is really ugly to boot.

ely · Accepted Answer

There is a hook left in the Descriptor protocol for this sort of thing -- namely, when the Descriptor object is accessed from the class level, the value of instance will be None.

It's useful to think about this in the reverse direction. Let's start with Circle:

class Circle(object):
    diameter = Length()
    def __init__(self, diameter, units):
        self.diameter = (diameter, units)

Notice that instead of trying to manually call __set__ or call things from the class level (e.g. by invoking from Circle directly) -- I am just using the descriptor as it is intended, simply setting a value.

Now, for the descriptor, virtually everything will be the same. I cleaned up the code style for the conversion dict.

But for __get__ I add the extra check for whenever instance == None. This will be the case whenever Circle.diameter is accessed, as opposed to c.diameter for some c that is an instance of Circle. Make sure you feel comfortable with the difference.

class Length(object):
    conversion = {'inches':1.0,
                  'centimeters':2.54,
                  'feet':1.0/12,
                  'meters':2.54/100}

    def __set__(self, instance, length):
        instance.__value = length[0]
        instance.__units = length[1]

    def __get__(self, instance, owner):
        if instance is None:
            return self
        return (instance.__value, instance.__units)

    def get_in(self, instance, units):
        c_factor = self.conversion[units] / self.conversion[instance.__units]
        return (c_factor * instance.__value, units)

Now, we can get a hold of the actual Length instance that lives inside of .diameter ... but only if we access .diameter hanging off of Circle (the class itself) and not any instances of that class.

# This works and prints the conversion for `c`.
c = Circle(12, 'inches')
Circle.diameter.get_in(c, 'feet')

# This won't work because you short-circuit as soon as you type `c.diameter`
c.diameter.get_in('feet')

One option to avoid needing to go outside of the instance is to monkey-patch a function that utilizes the __class__ attribute:

class Circle(object):
    diameter = Length()
    def __init__(self, diameter, units):
        self.diameter = (diameter, units)
        self.convert = lambda attr, units: (
            getattr(self.__class__, attr).get_in(self, units)
        )

Now the instance c can work like this:

>>> c.convert('diameter', 'feet')
(1.0, 'feet')

You could instead define convert as an instance method (e.g. with the usual self first argument), or you could do it with decorators, or metaclasses, ... etc.

But at the end of the day, you still need to be very careful. On the surface this looks attractive, but really you are adding a lot of coupling between your objects. It superficially might look like you're separating the concerns about unit conversion away from the object's concerns about "being a Circle" -- but really you're adding layers of complexity that other programmers will have to sort out. And you're marrying your class to this particular Descriptor. If someone determines in a refactoring that diameter conversion is better as a function wholly outside of the Circle object, they now suddenly have to worry about accurately accounting for all of the moving parts of Length when they do the refactoring.

At the end of the day, you also have to ask what this buys you. As far as I can tell, in your example it doesn't buy anything except the very minor convenience of being able to induce conversion calculation as part of the so-called "fluent interface" design style ... e.g. side-effects and function calls appear like they are merely attribute accesses.

Personally, I dislike this kind of syntax. I'd much rather use a style like

convert(c.diameter, 'feet')

than

Circle.diameter.convert('feet')

Functions like the first version usually live at a module level, and they can be generalized over the types which they will operate on. They can be extended to handle new types more easily (and you can encapsulate them into their own separate classes if you want inheritance on the functions). Usually, they are also easier to test because vastly less machinery is needed to invoke them, and the testing mock objects can be simpler. In fact, in a dynamically typed language like Python, allowing a function like convert to work based on duck typing is typically one of the major virtues of the language.

This is not to say one way is definitely better than the other. A good designer could find merits in either approach. A bad designer could make a mess out of either approach. But in general, I find that when these exceptional corners of Python are used to solve unexceptional, regular problems, it often leads to a confused mess.

Bind the instance argument of a descriptor method to the calling object instance

Answers (2)

Related Questions