Types of Descriptors

Re­sum­ing from where we left of­f, on the pre­vi­ous post, on which we took A first look at de­scrip­tors, it’s time to ex­plore their dif­fer­ent types and how they work in­ter­nal­ly.

In Python, almost everything is represented with a dictionary. Objects are dictionaries. Classes are objects, hence they also are contained into a dictionary. This is denoted by the __dict__ attribute that objects have.

There are two types of descriptors: data descriptors and non-data ones. If a descriptor implements both 1 __get__() and __set__(), it’s called a data descriptor; otherwise is a non-data descriptor.

Note

Da­ta de­scrip­tors take prece­dence over the in­stance’s dic­tio­nary of at­tributes, where­as in the case of a non-­da­ta de­scrip­tor, the in­stance’s in­ter­nal dic­tio­nary may be looked up first.

The difference between them, lies on how the properties in the object are accessed, meaning which path will the MRO (Method Resolution Order) of Python follow, in order to comply with our instruction.

For a non-­da­ta de­scrip­tor, when we have an state­ment like:

<instance>.<attribute> = <value>

Python will update the instance’s internal dictionary under the key for the name of the attribute, and store the value in it. This follows the default behaviour of setting an attribute in an instance because there is no __set__ defined to override it.

On the other hand, if we have a data descriptor (also called overriding descriptor), for the same instruction the __set__ method will be ran because it’s defined. And analogously, when we access the property like:

<instance>.<descriptor>

The __get__ on descriptor is what’s going to be called.

So, again, da­ta (over­rid­ing) de­scrip­tors take prece­dence over the in­ter­nal dic­tio­nary of an ob­jec­t, where­as non da­ta (non-over­rid­ing) ones do not.

Lookup on Non-data Descriptors

On the previous example, when the object was first created it didn’t have any values for their properties. If we inspect the object, and its class, we’ll see that it doesn’t have any keys set for 'tv', but the class does:

>>> media.__dict__
{}

>>> media.__class__.__dict__
mappingproxy({'__dict__': <attribute '__dict__' of 'VideoDriver' objects>,
              '__doc__': '...',
              '__module__': '...',
              '__weakref__': ...
              'screen': <Resolution at 0x...>,
              'tv': <Resolution at 0x...>})

When we run media.tv the first time, there is no key 'tv' on media.__dict__, so Python tries to search in the class, and founds one, it gets the object, sees that the object has a __get__, and returns whatever that method returns.

However when we set the value like media.tv = (4096, 2160), there is no __set__ defined for the descriptor, so Python runs with the default behaviour in this case, which is updating media.__dict__. Therefore, next time we ask for this attribute, it’s going to be found in the instance’s dictionary and returned. By analogy we can see that it doesn’t have a __delete__ method either, so when the instruction del media.tv runs, this attribute will be deleted from media.__dict__, which leaves us back in the original scenario, where the descriptor takes place, acting as a default value holder.

Functions are non-data descriptors

This is how methods work in Python: function objects, are non-data descriptors that implement __get__().

If we think about it, ac­cord­ing to ob­jec­t-ori­ent­ed soft­ware the­o­ry, an ob­ject is a com­pu­ta­tion­al ab­strac­tion that rep­re­sents an en­ti­ty of the do­main prob­lem. An ob­ject has a set of meth­ods that can work with, which de­ter­mines its in­ter­face (what the ob­ject is and can do) 2.

How­ev­er, in more tech­ni­cal terms, ob­jects are just im­ple­ment­ed with a da­ta struc­ture (that in Python are dic­tio­nar­ies), and it’s be­haviour, de­ter­mined by their meth­od­s, are just func­tion­s. Again, meth­ods are just func­tion­s. Let’s prove it 3.

If we have a class like this and in­spect its dic­tio­nary we’ll see that what­ev­er we de­fined as meth­od­s, are ac­tu­al­ly func­tions stored in­ter­nal­ly in the dic­tio­nary of the class.

class Person:
    def __init__(self, name):
        self.name = name

    def greet(self, other_person):
        print(f"Hi {other_person.name}, I'm {self.name}!")

We can see that among all the things de­fined in the class, it’s dic­tio­nary con­tains an en­try for ‘greet’, whose val­ue is a func­tion.

>>> type(Person.greet)
<class 'function'>

>>> Person.__dict__
mappingproxy({'__dict__': ...
              'greet': <function ...Person.greet>})

This means that in fact, it’s the same as having a function defined outside the class, that knows how to work with an instance of that same class, which by convention in Python is called self. Therefore inside the class, we’re just creating functions that know how to work with an instance of that class, and Python will provide this object, as a first parameter, under the name that we usually call self. This is basically what the __get__ method does for functions: it returns a bound instance of the function to that object.

In CPython, this logic is implemented in C, but let’s see if we can create an equivalent example, just to get a clear picture. Imagine we have a custom function, and we want to apply it to a class, as an instance method.

First we have an isolated function, that computes the mean time between failures for an object that collects metrics on systems that monitors. Then we have a class called SystemMonitor, that represents all sort of objects that collect metrics on monitored systems.

def mtbf(system_monitor):
    """Mean Time Between Failures
    https://en.wikipedia.org/wiki/Mean_time_between_failures
    """
    operational_intervals = zip(
        system_monitor.downtimes,
        system_monitor.uptimes)

    operational_time = sum(
        (start_downtime - start_uptime)
        for start_downtime, start_uptime in operational_intervals)
    try:
        return operational_time / len(system_monitor.downtimes)
    except ZeroDivisionError:
        return 0


class SystemMonitor:
    """Collect metrics on software & hardware components."""
    def __init__(self, name):
        self.name = name
        self.uptimes = []
        self.downtimes = []

    def up(self, when):
        self.uptimes.append(when)

    def down(self, when):
        self.downtimes.append(when)

For now we just test the function, but soon we’ll want this as a method of the class. We can easily apply the function to work with a SystemMonitor instance:

>>> monitor = SystemMonitor('prod')
>>> monitor.uptimes = [0,7, 12]
>>> monitor.downtimes = [5, 12]

>>> mtbf(monitor)
>>> 5.0

But now we want it to be part of the class, so that I can use it as a in­stance method. If we try to as­sign the func­tion as a method, it will just fail, be­cause it’s not bound:

>>> monitor.mtbf = mtbf
>>> monitor.mtbf()
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-7-...> in <module>()
----> 1 monitor.mtbf()

TypeError: mtbf() missing 1 required positional argument: 'system_monitor'

In this case the system_monitor positional argument that requires, is the instance, which in methods is referred to as self.

Now, if the function is bound to the object, the scenario changes. We can do that the same way Python does: __get__.

>>> monitor.mtbf = mtbf.__get__(monitor)
>>> monitor.mtbf()
5.0

Now, we want to be able to define this function inside the class, the same way we do with methods, like def mtbf(self):.... In this case, for simplicity, I’ll just use a callable object, that represents the actual object function (the body of __call__ would represent what we put on the body of the function after it’s definition). And we’ll declare it as an attribute of the class, much like all methods:

class SystemMonitor:
    ...
    mtbf = MTBF()

Provided that MTBF is a callable object (again, representing our “function”), is equivalent to doing def mtbf(self): ... inside the class.

In the body of the callable, we can just reuse the original function, for simplicity. What’s really interesting is the __get__ method, on which we return the callable object, exposed as a method.

class MTBF:
    """Compute Mean Time Between Failures"""
    def __call__(self, instance):
        return mtbf(instance)

    def __get__(self, instance, owner=None):
        return types.MethodType(self, instance)

To explain: the attribute mtbf is a “function” (callable actually), defined in the class. When we call it as a method, Python will see it has a __get__, and when this is called, it will return another object which is the function bound to the instance, passing self as first parameter, which in turn is what’s going to be executed.

This does the trick of making functions work as methods, which is a very elegant solution of CPython.

We can now ap­pre­ci­ate the el­e­gance of the de­sign be­hind meth­od­s: in­stead of cre­at­ing a whole new ob­jec­t, re­use func­tions un­der the as­sump­tion that the first pa­ram­e­ter will be an in­stance of that class, that is go­ing to be used in­ter­nal­ly, and by con­ven­tion called self (although, it can be called oth­er­wise).

Following a similar logic, classmethod, and staticmethod decorators, are also descriptors. The former, passes the class as the first argument (which is why class methods start with cls as a first argument), and the latter, simply returns the function as it is.

Lookup on Data Descriptors

On the previous example, when we assigned a value to the property of the descriptor, the instance dictionary was modified because there was no __set__ method on the descriptor.

For da­ta de­scrip­tors, un­like on the pre­vi­ous ex­am­ple, the meth­ods on the de­scrip­tor ob­ject take prece­dence, mean­ing that the lookup starts by the class, and does­n’t af­fect the in­stance’s dic­tio­nary. This is an asym­me­try, that char­ac­teris­es da­ta de­scrip­tors.

On the previous examples, if after running the descriptor, the __dict__ on the instance was modified, it was because the code explicitly did so, but it could have had a different logic.

class DataDescriptor:
    """This descriptor holds the same values for all instances."""
    def __get__(self, instance, owner):
        return self.value

    def __set__(self, instance, value):
        self.value = value

class Managed:
    descriptor = DataDescriptor()

If we run it, we can see, that since this descriptor holds the data internally, __dict__ is never modified on the instance 4:

>>> managed = Managed()
>>> vars(managed)
{}
>>> managed.descriptor = 'foo'
>>> managed.descriptor
'foo'
>>> vars(managed)
{}

>>> managed_2 = Managed()
>>> vars(managed_2)
{}
>>> managed_2.descriptor
'foo'

Method Lookup

The descriptors machinery is triggered by __getattribute__, so we have to be careful if we are overriding this method (better not), because if it’s not done properly, we might prevent the descriptor calls 5

Warn­ing

Classes might turn off the descriptor protocol by overriding __getattribute__.

1

http­s://­doc­s.python.org/3.6/how­to/de­scrip­tor.htm­l#de­scrip­tor-pro­to­col

2

Duck typ­ing

3

This means that in re­al­i­ty, ob­jects are just da­ta struc­tures with func­tions on it, much like ADT (Ab­stract Da­ta Type­s) in C, or the structs de­fined in Go with the func­tions that work over them. A more de­tailed anal­y­sis and ex­pla­na­tion of this, de­serves a sep­a­rate post.

4

This is not a good prac­tice, (ex­cept for very par­tic­u­lar sce­nar­ios that might re­quire it, of course), but it’s shown on­ly to sup­port the idea.

5

http­s://­doc­s.python.org/3/how­to/de­scrip­tor.htm­l#in­vok­ing-de­scrip­tors