Stop Writing Getter and Setter Methods. Use @property Instead.

I remember the first time I saw @property in a Python codebase. I was confused. It looked like a method but was being accessed like a regular attribute. It felt like magic. But after I understood it, I couldn't imagine writing Python classes any other way. The @property decorator is one of those features that turns good code into elegant code. Let me show you why.

The Problem: Why We Need Computed Attributes

Imagine you're building a user profile system for PythonSkillset.com. Each user has a first name and last name. You need a full name display. The obvious approach:

class User:
    def __init__(self, first, last):
        self.first = first
        self.last = last
        self.full_name = f"{first} {last}"

Looks fine? Except what happens when someone changes the first name:

user = User("Jane", "Doe")
print(user.full_name)  # "Jane Doe"
user.first = "Janet"
print(user.full_name)  # Still "Jane Doe" — bug!

Your full_name is now stale. You could write a method to recalculate it:

class User:
    def __init__(self, first, last):
        self.first = first
        self.last = last

    def get_full_name(self):
        return f"{self.first} {self.last}"

This works, but now you have user.get_full_name() everywhere. If you ever change from a computed attribute to a stored one, you break all your callers. This is exactly the problem @property solves.

@property: The Clean Solution

@property lets you define a method that behaves like a simple attribute. Callers use dot notation, not parentheses. Here's how it works:

class User:
    def __init__(self, first, last):
        self.first = first
        self.last = last

    @property
    def full_name(self):
        return f"{self.first} {self.last}"

Now user.full_name is always up-to-date:

user = User("Jane", "Doe")
print(user.full_name)  # "Jane Doe"
user.first = "Janet"
print(user.full_name)  # "Janet Doe" — correct!

No parentheses. No stale data. Clean code.

Property Setters: When You Need Write Access Too

Sometimes you want to compute an attribute when setting it too. For PythonSkillset.com's article system, you might store publication dates as timestamps but want to work with readable dates:

from datetime import datetime

class Article:
    def __init__(self, title):
        self.title = title
        self._published_timestamp = None

    @property
    def published_date(self):
        if self._published_timestamp is None:
            return None
        return datetime.fromtimestamp(self._published_timestamp).strftime("%Y-%m-%d")

    @published_date.setter
    def published_date(self, date_str):
        dt = datetime.strptime(date_str, "%Y-%m-%d")
        self._published_timestamp = dt.timestamp()

Usage is clean and natural:

article = Article("Understanding Python Properties")
article.published_date = "2024-01-15"
print(article.published_date)  # "2024-01-15"
# Internally, it's stored as a timestamp
print(article._published_timestamp)  # 1705276800.0

Validation: The Killer Feature

Properties shine when you need validation without cluttering your code. Let's say you're managing user ages on PythonSkillset:

class User:
    def __init__(self, name, age=0):
        self.name = name
        self._age = 0
        self.age = age  # Uses the setter

    @property
    def age(self):
        return self._age

    @age.setter
    def age(self, value):
        if not isinstance(value, (int, float)):
            raise TypeError("Age must be a number")
        if value < 0 or value > 150:
            raise ValueError("Age must be between 0 and 150")
        self._age = value

Now invalid ages raise clear errors right at assignment:

user = User("Alice")
user.age = 25  # Works
user.age = -5  # ValueError: Age must be between 0 and 150
user.age = "old"  # TypeError: Age must be a number

Your attribute assignment now carries business logic without making callers remember to validate.

Computed Properties: Real-World Example

At PythonSkillset, we track article performance. A property can compute complex values from stored data:

class ArticleStats:
    def __init__(self, views, likes, comments):
        self.views = views
        self.likes = likes
        self.comments = comments

    @property
    def engagement_rate(self):
        if self.views == 0:
            return 0.0
        return round((self.likes + self.comments * 2) / self.views * 100, 2)

    @property
    def is_viral(self):
        return self.engagement_rate > 10

These properties compute values on-the-fly from the base data:

stats = ArticleStats(views=5000, likes=320, comments=45)
print(stats.engagement_rate)  # (320 + 90) / 5000 * 100 = 8.2%
print(stats.is_viral)  # False
# If engagement changes, properties update automatically
stats.likes = 600
print(stats.engagement_rate)  # Now 13.8%
print(stats.is_viral)  # True

The Hidden Benefit: Backward Compatibility

Here's the real-world win. Imagine you built a system storing temperature in Celsius everywhere. Later you need to support Fahrenheit. Without properties, you'd refactor every temp_celsius reference. With properties, you just:

class Weather:
    def __init__(self, temp_celsius):
        self._temp_celsius = temp_celsius

    @property
    def temp_celsius(self):
        return self._temp_celsius

    @temp_celsius.setter
    def temp_celsius(self, value):
        self._temp_celsius = value

    @property
    def temp_fahrenheit(self):
        return self._temp_celsius * 9/5 + 32

Your existing code using temp_celsius continues working. New code can use temp_fahrenheit. No breaking changes.

When NOT to Use @property

Properties are powerful, but not always right. Avoid them when:

1. The computation is expensive — If every access runs a database query or heavy calculation, use a regular method. @property implies "cheap to compute."

2. The value changes each time — Properties that return random numbers, current time, or state-dependent values surprise developers. user.generate_token() is clearer than user.token.

3. You need to pass parameters — Properties can't take arguments. article.search_by_tag("python") makes sense. article.by_tag("python") doesn't.

The Bottom Line

@property is Python's way of letting you write methods that feel like attributes. It's not about saving keystrokes — it's about designing interfaces that are intuitive and maintainable. Next time you write a get_ method that just returns a computed value, ask yourself: "Should this be a property?" The answer is often yes.

At PythonSkillset.com, we've refactored dozens of classes to use properties. The result? Cleaner code, fewer bugs, and happier developers. Give it a try — you'll see the difference.