Python @property: Getters and Setters

3Python Properties: explained step by step

Imagine a Thermostat class that stores a temperature in Celsius. A plain attribute is perfect at first: room.celsius = 21. Then two new requirements arrive. Nobody should be able to store a temperature below absolute zero, and other code also wants the Fahrenheit value. A property lets you add both rules without changing how the class is used.

The problem with plain attributes

A plain attribute accepts anything you hand it:

class Thermostat:
    def __init__(self, celsius):
        self.celsius = celsius

room = Thermostat(21)
room.celsius = -500        # physically impossible, but Python does not mind
print(room.celsius)

Two different situations call for something smarter:

• The value must stay valid. You want to check every new value before it is stored.
• The value can be worked out from other data. If you store full_name next to first_name and last_name, the copies drift apart the moment one of them changes. It is safer to compute the value when someone asks for it.

A read-only computed attribute with @property

Put @property above a method that takes only self. Python then lets you read it without parentheses, exactly like a stored attribute:

class Person:
    def __init__(self, first_name, last_name):
        self.first_name = first_name
        self.last_name = last_name

    @property
    def full_name(self):
        return f"{self.first_name} {self.last_name}"

asha = Person("Asha", "Rao")
print(asha.full_name)         # no parentheses
asha.last_name = "Verma"
print(asha.full_name)         # always up to date

Nothing called full_name is stored anywhere. The method runs every time you ask, so the answer can never be out of date. Because there is no setter, trying asha.full_name = "Someone Else" fails with AttributeError: property 'full_name' of 'Person' object has no setter. The property is read-only, which is often exactly what you want.

A setter that validates

To make a property writable, add a second method with the same name, decorated with @name.setter. It receives the new value and decides whether to accept it. The real value lives in a separate attribute whose name starts with an underscore (_celsius) — the "internal detail" convention from the encapsulation lesson.

class Thermostat:
    def __init__(self, celsius):
        self.celsius = celsius        # goes through the setter, so it is checked too

    @property
    def celsius(self):
        return self._celsius

    @celsius.setter
    def celsius(self, value):
        if value < -273.15:
            raise ValueError("temperature cannot be below absolute zero")
        self._celsius = value

room = Thermostat(21)
room.celsius = 25
print(room.celsius)
try:
    room.celsius = -500
except ValueError as err:
    print("Rejected:", err)
print(room.celsius)

Notice three things. Callers still write room.celsius = 25; nothing about the syntax changed. __init__ assigns to self.celsius (not self._celsius), so even the very first value goes through the check. And the rejected value never reaches _celsius, so the object keeps its last valid state.

Why not get_celsius() and set_celsius()?

In some languages you write getter and setter methods for every field "just in case", because changing a plain field into a method later would break every caller. Python avoids that problem: you start with a plain attribute, and if you later need validation or computation, you turn it into a property. Every line that already uses room.celsius keeps working unchanged. So don't write get_x() and set_x() in Python.

Computing on access (and caching)

A property can do any amount of work: sum a list, format text, combine other attributes. Because it runs on every access, the result is never stale.

class Cart:
    def __init__(self):
        self.prices = []

    @property
    def total(self):
        return round(sum(self.prices, 0.0), 2)

    @property
    def is_empty(self):
        return not self.prices

cart = Cart()
print(cart.is_empty, cart.total)
cart.prices.extend([4.99, 12.5])
print(cart.is_empty, cart.total)

If the work is slow and the data rarely changes, you can remember the answer in a private attribute and clear it whenever the data changes. Python's functools.cached_property does the "compute once" part for you (there is an example on the examples page).

Deleting with @x.deleter

del obj.x normally removes an attribute. For a property you decide what deleting means, usually a bit of clean-up. You will need this rarely, but it completes the set of three hooks: read, write, delete.

class Profile:
    def __init__(self, nickname):
        self._nickname = nickname

    @property
    def nickname(self):
        return self._nickname or "anonymous"

    @nickname.deleter
    def nickname(self):
        print("clearing nickname")
        self._nickname = None

user = Profile("pixel")
print(user.nickname)
del user.nickname
print(user.nickname)

The classic trap: RecursionError

Beginners often write the setter like this (shown as plain text on purpose, because it never finishes):

@celsius.setter
def celsius(self, value):
    self.celsius = value      # WRONG: this assigns to the property again

self.celsius = value is itself an assignment to the property, so Python calls the setter again, which assigns again, which calls the setter again... until Python gives up with RecursionError: maximum recursion depth exceeded. The same happens in the getter if it does return self.celsius. The rule: the property name is the public door; the data lives behind it under a different name, usually _celsius.

When a plain attribute is better

A property costs extra lines, and readers will assume something clever is going on. If a value is just stored and read, with no checks and no calculation, keep it a plain attribute. Start plain; upgrade to a property the day you need one, and no caller will notice.

Also keep properties quick and free of surprises. If reading a value takes seconds, talks to the network or changes other data, make it a method with a verb name (load_report()) so the parentheses warn the reader that work happens.