Put very simply, a descriptor is a class that can be used to call a method with simple attribute access, but there’s obviously more to it than that. It’s difficult to explain beyond that without digging a little into how descriptors implemented. So, here’s a high-level view of the descriptor protocol.
A descriptor implements at least one of these three methods: __get__(), __set__(), or __delete__(). Each of those methods has a list of parameters needed, which will be discussed a little later, and each is called by a different sort of access of the attribute the descriptor represents. Doing simple a.x access will call the __get__() method of x; setting the attribute using a.x = value will call the __set__() method of x; and using del a.x will call, as expected, the __delete__() method of x.
Note
Since version 3.6, there’s another method that descriptors can take advantage of, called __set_name__(), but using just that method doesn’t make it a descriptor the way any of the other three will. This method will be mostly ignored for a while, since it doesn’t have as big a role into how descriptors work. It will only be mentioned where most relevant.
As stated, only one of the methods needs to be implemented in order to be considered a descriptor, but any number of them can be implemented. And, depending on descriptor type and on which methods are implemented, not implementing certain methods can restrict certain types of attribute access or provide interesting alternative behaviors for them. There are two types of descriptors based on which sets of these methods are implemented: data and non-data.
Data Descriptors versus Non-Data Descriptors
A data descriptor implements at least __set__() or __delete__(), but can include both. Data descriptors also often include __get__() since it’s rare to want to set something without also being able to get it too. You can get the value, even if the descriptor doesn’t include __get__(), but it’s either roundabout or the descriptor writes it to the instance. That will be discussed more later.
A non-data descriptor only implements __get__(). If it adds a __set__() or __delete__() method, it becomes a data descriptor.
Unfortunately, the PyPy interpreter (up to version 2.4.0) gets this a little bit wrong. It doesn’t take __delete__() into consideration until it knows that it’s a data descriptor, and PyPy doesn’t believe something is a data descriptor unless __set__() is implemented. Luckily, since a huge majority of data descriptors implement __set__(), this rarely becomes a problem.
It may seem like the distinction is pointless, but it is not. It comes into play upon attribute lookup. This will be discussed more later, but basically, the distinction is the types of uses it provides.
The Use of Descriptors by Python
It is worth noting that descriptors are an inherent part of how Python works. Python is known to be a multi-paradigm language, and as such supports paradigms such as functional programming, imperative programming, and object-oriented programming. This book does not attempt to go into depth about the different paradigms; only the object-oriented programming paradigm will be observed. Descriptors are used implicitly in Python for the language’s object-oriented mechanisms. As will be explained shortly, methods are implemented using descriptors. As you may guess from reading this, it is thanks to descriptors that object-oriented programming is possible in Python. Descriptors are very powerful and advanced, and this book aims to teach Python programmers how to use them fully.
Summary
As you have seen, descriptors occupy a large part of the Python language, as they can replace attribute access with method calls, and even restrict which types of attribute access is allowed. Now that you have a broad idea of how descriptors are implemented as well as their use by the language, we will dig a little deeper yet, gaining a better understanding of how they work.