Python Property Validation: Using @property Setters

When a Python class exposes attributes through @property, the setter is the natural place to enforce validation rules. Without validation, an object can be assigned values that break invariants, such as a negative price or an empty username. This article shows how to implement python property validation using setters, raise appropriate exceptions, and decide when a more elaborate mechanism is warranted.

Why the Setter Is the Right Place for Validation

In Python, @property turns a method into a managed attribute. The setter method is called whenever the attribute is assigned, so it gives you a single point of control. Consider a simple Product class:

class Product:
    def __init__(self, name: str, price: float):
        self.name = name
        self.price = price

    @property
    def price(self) -> float:
        return self._price

    @price.setter
    def price(self, value: float) -> None:
        self._price = value

This setter currently accepts any value. If you assign product.price = -5, the object silently stores a negative price. Adding validation inside the setter prevents that state from ever existing. This is preferable to checking the value at every use site because it keeps the invariant local to the attribute definition.

Raising Meaningful Exceptions

The standard way to reject an invalid value is to raise ValueError or TypeError. ValueError is appropriate when the value is of the right type but out of range, while TypeError is for wrong types. The setter should raise immediately so the object never enters an inconsistent state.

class Product:
    def __init__(self, name: str, price: float):
        self.name = name
        self.price = price

    @property
    def price(self) -> float:
        return self._price

    @price.setter
    def price(self, value: float) -> None:
        if not isinstance(value, (int, float)):
            raise TypeError(f"price must be a number, got {type(value).__name__}")
        if value < 0:
            raise ValueError(f"price must be non-negative, got {value}")
        self._price = value

Now product.price = -1 raises ValueError and product.price = "abc" raises TypeError. The error messages include the offending value and the expected constraint, which helps debugging. This pattern is straightforward and works for any attribute that needs a simple range or type check.

Combining Multiple Validation Rules

Real-world attributes often need more than one check. For example, a username must be a non-empty string and may have a maximum length. You can chain conditions inside the setter, but the logic can become unwieldy. A cleaner approach is to delegate to a private method that returns a boolean or raises an exception.

class User:
    def __init__(self, username: str):
        self.username = username

    @property
    def username(self) -> str:
        return self._username

    @username.setter
    def username(self, value: str) -> None:
        self._validate_username(value)
        self._username = value

    def _validate_username(self, value: str) -> None:
        if not isinstance(value, str):
            raise TypeError("username must be a string")
        if not value.strip():
            raise ValueError("username cannot be empty")
        if len(value) > 50:
            raise ValueError("username must be 50 characters or fewer")

This separates validation from assignment, making the setter readable. The private method can be reused if the same rules apply to other attributes, though in practice you might extract a validator function or class.

Comparing with setattr and Descriptors

@property is not the only way to intercept attribute assignment. Overriding __setattr__ gives you a global hook for all attributes, but it requires manual type checks and can interfere with internal assignments. Descriptors are reusable and can encapsulate validation logic, but they add boilerplate.

A descriptor that validates a range looks like this:

class PositiveFloat:
    def __set_name__(self, owner, name):
        self.name = name

    def __get__(self, obj, objtype=None):
        return obj.__dict__[self.name]

    def __set__(self, obj, value):
        if not isinstance(value, (int, float)):
            raise TypeError(f"{self.name} must be a number")
        if value < 0:
            raise ValueError(f"{self.name} must be non-negative")
        obj.__dict__[self.name] = value

class Product:
    price = PositiveFloat()

Descriptors are useful when the same validation rule applies to many attributes across different classes. However, for a single attribute, @property is simpler and more explicit. The choice depends on how often the rule is reused.

When Dataclasses and Pydantic Are Better Alternatives

Python's dataclasses module does not include built-in validation, but you can add a __post_init__ method to check values after initialization. This works well for objects that are mostly immutable and validated once at construction time. For mutable attributes that need ongoing validation, @property is more direct.

Third-party libraries like Pydantic provide declarative validation through type hints and field constraints. They are powerful for data models that come from external sources, such as JSON payloads, and they handle nested validation and serialization. However, they add a dependency and a different mental model. For a small internal class, a setter is often sufficient.

The following table summarizes the tradeoffs:

Performance and Maintainability Considerations

Property setters add a function call on every assignment. In most applications this overhead is negligible, but in tight loops that assign attributes millions of times, it can matter. If performance is critical, you can bypass the setter by directly writing to self._price inside the class, but that breaks encapsulation and can lead to inconsistent state. Profile before optimizing.

Maintainability is the bigger concern. Validation logic scattered across many setters becomes hard to update when rules change. Centralizing rules in a validator function or using a descriptor reduces duplication. Also, remember that @property setters are invoked only on assignment, not when the attribute is mutated in place. For example, if an attribute is a list, obj.items.append(x) does not trigger the setter. If you need to validate list contents, you must override list methods or use a custom container.

Edge Cases: Inheritance and Immutable Properties

When a subclass overrides a property setter, it must preserve the validation contract. Calling super().setter is not automatic; you need to explicitly call the parent setter if you want to extend behavior. For example:

class DiscountedProduct(Product):
    @Product.price.setter
    def price(self, value: float) -> None:
        if value > 100:
            raise ValueError("discounted price too high")
        super(DiscountedProduct, DiscountedProduct).price.fset(self, value)

This is verbose but necessary. Alternatively, you can design the base class with a protected validation method that subclasses can override.

Immutable properties are another edge case. If you want an attribute to be read-only, you can define a property without a setter. Attempting to assign to it raises AttributeError. This is useful for values derived from other attributes, but it prevents validation because no value can ever be assigned after initialization.

Finally, type hints do not enforce validation. A setter that checks isinstance(value, int) is stricter than a type hint, which is only for static analysis. Use both when you need runtime guarantees and editor support.