Python's property(): Add Managed Attributes to Your Classes

The Getter and Setter Approach in Python

Technically, there’s nothing that stops you from using getter and setter methods in Python. Here’s a quick example that shows how this approach would look:

In this example, you create a Point class with two non-public attributes ._x and ._y to hold the Cartesian coordinates of the point at hand.

To access and mutate the value of either ._x or ._y, you can use the corresponding getter and setter methods. Go ahead and save the above definition of Point in a Python module and import the class into an interactive session. Then run the following code:

With .get_x() and .get_y(), you can access the current values of ._x and ._y. You can use the setter method to store a new value in the corresponding managed attribute. From the two final examples, you can confirm that Python doesn’t restrict access to non-public attributes. Whether or not you access them directly is up to you.

The Pythonic Approach

Even though the example you just saw uses the Python coding style, it isn’t Pythonic. In the example, the getter and setter methods don’t perform any further processing with the values of ._x and ._y, so you could just have plain attributes instead of methods.

You can rewrite Point in a more concise and Pythonic way:

This code uncovers a fundamental Python principle: exposing attributes to the end user is normal and common. This is cool because you don’t need to clutter your classes with getter and setter methods all the time.

The question is, how do you handle requirement changes that would imply modifying the implementation of attributes without changing your APIs? For example, say that you need to add validation functionality on top of a given attribute. How would you do that if your attribute doesn’t have setter and getter methods where you can put that functionality?

Unlike Java and C++, Python provides handy tools that allow you to change the underlying implementation of your attributes without changing your public API. The most popular approach is to turn your attributes into properties.

Properties represent an intermediate functionality between a plain attribute, or field, and a method. In other words, they allow you to create methods that behave like attributes. With properties, you can change how you compute the target attribute whenever you need to.

For example, you can turn both .x and .y into properties. With this change, you can continue to access them as attributes while having them perform actions when your users access and mutate them.

Python properties allow you to expose attributes as part of your classes’ public APIs. If you ever need to change an attribute’s underlying implementation, then you can conveniently turn it into a property at any time. In the following sections, you’ll learn how to create properties in Python.

Creating Attributes With property()

You can create a property by calling property() with an appropriate set of arguments and assigning its return value to a class attribute. All the arguments to property() are optional. However, you typically provide at least a getter function.

The following example shows how to create a Circle class with a property that manages its radius:

In this code snippet, you create Circle. The class initializer, .__init__(), takes radius as an argument and stores it in a non-public attribute called ._radius. Then, you define three non-public methods:

1. ._get_radius() returns the current value of ._radius
2. ._set_radius() takes value as an argument and assigns it to ._radius
3. ._del_radius() deletes the instance attribute ._radius

Once you have these three methods in place, you create a class attribute called .radius to store the property object. To initialize the property, you pass the three methods as arguments to property(). You also pass a suitable docstring for your property.

In this example, you use keyword arguments to improve readability and prevent confusion. That way, you know exactly which method goes into each argument.

To give Circle a try, run the following code in your Python REPL:

The .radius property hides the non-public instance attribute ._radius, which is now your managed attribute in this example. You can access and assign .radius directly. Internally, Python automatically calls ._get_radius() and ._set_radius() when needed. When you execute del circle.radius, Python calls ._del_radius(), which deletes the underlying ._radius.

Properties are class attributes that manage instance attributes. You can think of a property as a collection of methods bundled together. If you inspect .radius carefully, then you’ll find the raw methods you provided as the fget, fset, and fdel arguments:

You can access the getter, setter, and deleter methods in a given property through the corresponding .fget, .fset, and .fdel attributes.

Properties are also descriptors. If you use dir() to check the internal members of a given property, then you’ll find .__set__() and .__get__() in the list. These methods provide a default implementation of the descriptor protocol.

The default implementation of .__set__(), for example, runs when you don’t provide a custom setter method. This implementation gives you an AttributeError when you try to set the attribute.

Using property() as a Decorator

Decorators are frequently used in Python. They’re typically functions that take another function as an argument and return a new function with added functionality. With a decorator, you can attach pre- and post-processing operations to an existing function.

The decorator syntax consists of placing the name of the decorator function with a leading @ symbol right before the definition of the function you want to decorate:

In this code, @decorator can be a function or class intended to decorate function(). This syntax is equivalent to the following:

The final line of code reassigns the name function to hold the result of calling decorator(function). Note that this is the same syntax you used to create a property in the previous section.

Python’s property() can work as a decorator, so you can use the @property syntax to create your properties quickly:

Circle now is more Pythonic and clean. You don’t need to use method names such as ._get_radius(), ._set_radius(), and ._del_radius() anymore. Now you have three methods with the same descriptive attribute-like name. How’s that possible?

The decorator approach for creating properties requires defining a first method using the public name for the underlying managed attribute, which is .radius in this example. This method should implement the getter logic. In the above example, lines 5 to 9 implement that method.

Lines 11 to 14 define the setter method for .radius. The syntax is different. Instead of using @property again, you use @radius.setter. Why do you need to do that? Take a look at the dir() output:

Besides .fget, .fset, .fdel, and a bunch of other special attributes and methods, property also provides .deleter(), .getter(), and .setter(). These three methods each return a new property.

When you decorate the second .radius() method with @radius.setter on line 11, you create a new property and reassign the class-level name .radius from line 6 to hold it. This new property contains the same set of methods of the initial property on line 6 with the addition of the new setter method provided on line 12. Finally, the decorator syntax reassigns the new property to the .radius class-level name.

The mechanism to define the deleter method is similar. This time, you need to use the @radius.deleter decorator. At the end of the process, you get a full-fledged property with the getter, setter, and deleter methods.

Now, how can you provide suitable docstrings for your properties when you use the decorator approach? If you check Circle again, you’ll notice that you already did so by adding a docstring to the getter method on line 7.

The new Circle implementation works the same as the example in the section above:

First, note that you don’t need to use a pair of parentheses for calling .radius() as a method. Instead, you can access .radius as you would access a regular attribute, which is the primary purpose of properties. They allow you to treat methods as attributes.

Here’s a recap of some important points to remember when you’re creating properties with the decorator approach:

• The @property decorator must decorate the getter method.
• The docstring must go in the getter method.
• The setter and deleter methods must be decorated with the name of the getter method plus .setter and .deleter, respectively.

Up to this point, you’ve learned how to create managed attributes using property() as a function and a decorator. It’s time to think about when you should use properties.

Validating Input Values

Validating input is one of the most common use cases of property() and managed attributes. Data validation is a common requirement in code that takes input from users or other sources that you could consider untrusted. Python’s property() provides a quick and reliable tool for dealing with input validation.

For example, getting back to the Point class, you may require the values of .x and .y to be valid numbers. Since your users are free to enter any type of data, you need to make sure that your points only accept numbers.

Here’s an implementation of Point that manages this requirement:

The setter methods of .x and .y use try … except blocks that validate input data using the Python EAFP (easier to ask forgiveness than permission) style. If the call to float() succeeds, then the input data is valid, and you get Validated! on your screen. If float() raises a ValueError, then the user gets a ValueError with a more specific message.

It’s important to note that assigning the .x and .y properties directly in .__init__() ensures that the validation also occurs during object initialization. Not doing so can lead to issues when using property() for data validation.

Here’s how your Point class works now:

If you assign .x and .y values that float() can turn into floating-point numbers, then the validation is successful, and the value is accepted. Otherwise, you get a ValueError.

This implementation of Point uncovers a fundamental weakness of property(). Did you spot it? That’s it! You have repetitive code that follows specific patterns. This repetition breaks the DRY (Don’t Repeat Yourself) principle, so you would want to refactor this code to avoid it. To do so, you can abstract out the repetitive logic using a descriptor that you can call Coordinate:

Now your code is a bit shorter and way less repetitive. You defined Coordinate as a descriptor to manage the data validation in a single place. Then, you create .x and .y as class attributes holding instances of the target descriptor. The code works just like its earlier implementation. Go ahead and give it a try!

In general, if you find yourself copying and pasting property definitions throughout your code or if you spot repetitive code, like in the example above, then you should consider using descriptors.

Providing Computed Attributes

If you need an attribute that builds its value dynamically whenever you access it, then using a property can be a great choice. These kinds of attributes are commonly known as computed attributes. They’re handy when you need something that works like an eager attribute, but you want it to be lazy.

The main reason for creating lazy attributes is to postpone their computation until the attributes are needed, which can make your code more efficient.

Here’s an example of how to use property() to create a computed attribute called .area in a Rectangle class:

In this example, the Rectangle initializer takes width and height as arguments and stores them in the corresponding instance attributes. The read-only property, .area, computes and returns the area of the current rectangle every time you access it.

Another cool use case of properties is to provide a formatted value for a given attribute:

In this example, .price is a property that formats and returns the price of a particular product. To provide a currency-like format, you use an f-string with an appropriate format specifier.

As a final example of computed attributes, say you have a Point class that uses .x and .y as Cartesian coordinates. You want to provide polar coordinates for your point so that you can use them in a few computations. The polar coordinate system represents each point using the distance to the origin and the angle with the horizontal coordinate axis.

Here’s a Cartesian coordinates Point class that also provides computed polar coordinates:

In this example, you define two properties to compute the polar coordinates—distance and angle—of a given Point object using its .x and .y Cartesian coordinates. You also add two instance methods that return the Cartesian and polar coordinates as tuples.

Here’s how this class works in practice:

Properties are handy tools for providing computed attributes. However, if you’re creating an attribute that you use frequently, then computing it every time can be costly and wasteful. A good strategy to avoid this additional cost is to cache the computed value once the computation is done. That’s what you’ll do in the following section.

Caching Computed Attributes

Sometimes you have a given computed attribute that you use frequently. Constantly running the same computation may be unnecessary and expensive. To work around this problem, you can cache the computed value for later reuse.

If you have a property that computes its value from constant input values, then the result will never change. In that case, you can compute the value just once:

This implementation of Circle caches the computed diameter using a dedicated non-public attribute. The code works, but it has the drawback that if you ever change the value of .radius, then .diameter won’t return a correct value:

In these examples, you create a circle with a radius equal to 42.0. The .diameter property computes its value only the first time you access it. That’s why you see a delay in the first execution and no delay in the second. When you change the value of the radius, the diameter stays the same, which is a problem.

If the input data for a computed attribute changes, then you need to recalculate its value:

The setter method of the .radius property resets ._diameter to None every time you change the radius. With this little update, .diameter recalculates its value the first time you access it after every mutation of .radius:

Cool! Circle works correctly now! It computes the diameter the first time you access it and also every time you change the radius.

Another way to create cached properties is to use functools.cached_property() from the standard library. This function works as a decorator and allows you to transform a method into a cached property. The property computes its value only once and caches it as a normal attribute during the lifetime of the instance:

Here, .diameter computes and caches its value the first time you access it. This kind of implementation is suitable for input values that don’t change. Here’s how it works:

When you access .diameter, you get its computed value. That value remains the same from this point on. However, unlike property(), cached_property() doesn’t block attribute updates unless you provide a setter method. That’s why you can update the diameter to 200 in the last couple of lines.

If you want to create a cached property that doesn’t allow modifications, then you can use property() and functools.cache() like in the following example:

This code stacks @property on top of @cache. The combination of both decorators builds a cached property that prevents changes:

In these examples, when you try to assign a new value to .diameter, you get an AttributeError because the setter functionality comes from the property’s internal descriptor.

Logging Attribute Access and Mutation

Sometimes, you need to keep track of what your code does and how your programs flow. A way to do that in Python is to use logging. This module provides all the functionality you require for logging your code. It allows you to constantly watch the code and generate useful information about how it works.

If you ever need to keep track of how and when you access and mutate a given attribute, then you can take advantage of property() for that, too:

Here, you first import logging and define a basic configuration. Then you implement Circle with a managed attribute .radius. The getter method generates log information every time you access .radius in your code. The setter method logs each mutation that you perform on .radius. It also logs those situations in which you get an error because of bad input data.

Here’s how you can use Circle in your code:

Logging data from attribute access and mutation can help you debug your code. Logging can also help you identify sources of problematic data input, analyze the performance of your code, spot usage patterns, and more.

Managing Attribute Deletion

You can create properties that implement deletion functionality. This might be a rare use case of property(), but having a way to delete an attribute can be handy in some situations.

Say you’re implementing your own tree data type. A tree is an abstract data type that stores elements in a hierarchy. The tree components are commonly known as nodes. Each node in a tree has a parent node, except for the root node. Nodes can have zero or more children.

Now, suppose you need to delete or clear the list of children of a given node. Here’s an example that implements a tree node that uses property() to provide most of its functionality, including the ability to clear the node’s list of children:

In this example, TreeNode represents a node in your custom tree data type. Each node stores its children in a Python list. Then, you implement .children as a property to manage the underlying list of children. The deleter method calls .clear() on the list of children to remove them all.

Here’s how your class works:

In this example, you first create a root node to initialize the tree. Then, you create two new nodes and assign them to .children using a list. The del statement triggers the internal deleter method of .children and clears the list of nodes.

Creating Backward-Compatible Class APIs

As you already know, properties turn direct attribute lookups into method calls. This feature allows you to create clean and Pythonic APIs for your classes. You can expose your attributes publicly without using getter and setter methods.

If you ever need to modify how you compute a given public attribute, then you can turn it into a property. Properties allow you to perform extra processing, such as data validation, without having to modify your public APIs.

Suppose you’re creating an accounting application and need a base class to manage currencies. To this end, you create a Currency class that exposes two attributes, .units and .cents:

This class looks clean and Pythonic. Now, say that your requirements change, and you decide to store the total number of cents instead of the units and cents. Removing .units and .cents from your public API to use something like .total_cents could break the code of more than one user.

In this situation, property() can be an excellent option to keep your current API unchanged. Here’s how you can work around the problem and avoid breaking your users’ code:

Now your class stores the total number of cents instead of independent units and cents. Because of the new properties, your users can still access and mutate .units and .cents in their code and get the same result as before. Go ahead and give it a try!

When you write code that others will build upon, you need to guarantee that modifications to your code’s internal implementation don’t affect how end users work with it.