{"title":"Getters & Setters","description":"","content":"In many object-oriented languages, the standard advice is \"never expose a field directly\". Wrap every value in `getX()` and `setX(value)` methods, even if those methods do nothing, just in case you need to add validation later. Python takes a different stance: start with a plain attribute, and add accessors only when you have a reason. This lesson covers why the Java-style pattern is an anti-pattern in Python, when you do need to intercept reads and writes, how to evolve a plain attribute into a property without breaking callers, and the small set of advanced hooks that exist for the unusual cases.\n\n---\n\n# Why the Java-Style Pattern Doesn't Fit Python\n\nIn a language where the syntax for \"read a field\" (`obj.field`) is permanently different from the syntax for \"call a method\" (`obj.getField()`), once a class exposes a public field, anyone who touches it has hard-coded the field-access form into their code. If you later need to add validation, you have to change every call site too. So the defensive habit is to write the getter and setter from day one, just in case.\n\nPython doesn't have this problem because the syntax for reading an attribute and the syntax for reading a property are identical. Both are `obj.field`. The difference between \"field\" and \"method-backed property\" is hidden behind the dot. Adding validation later costs zero changes at the call site.\n\nA minimal product class:\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n self.name = name\n self.price = price\n\nmouse = Product(\"Wireless Mouse\", 29.99)\nprint(mouse.price)\nmouse.price = 24.99\nprint(mouse.price)\n```\n\n\nThree weeks later, someone wants to reject negative prices. In Java, if `setPrice(value)` had been written from the start, you'd add the check inside that method and be done. Otherwise, you'd be renaming `product.price = ...` to `product.setPrice(...)` at every call site, which is a depressing afternoon.\n\nIn Python, you don't have to make that defensive choice up front. Keep the plain attribute version of `Product`, ship it, and only when the validation requirement appears do you swap the attribute for a property. The caller's code doesn't change:\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n self.name = name\n self.price = price\n\n @property\n def price(self):\n return self._price\n\n @price.setter\n def price(self, value):\n if value < 0:\n raise ValueError(\"price cannot be negative\")\n self._price = value\n\nmouse = Product(\"Wireless Mouse\", 29.99)\nprint(mouse.price)\nmouse.price = 24.99\nprint(mouse.price)\n```\n\n\nThat outer code is the same in both snippets. The class internals differ (the second version routes every read through a getter and every write through a setter), but the difference isn't visible from the outside. That's why Python doesn't preempt with getter/setter ceremony: the upgrade path is invisible to the caller.\n\nThis is the design pattern people are calling out when they say \"premature getters and setters are an anti-pattern in Python\". The pattern isn't wrong because accessors are bad; it's wrong because writing `set_price` before it's needed commits to a noisier API for no benefit. Start with the simplest form. Add machinery when something requires it.\n\n\n```mermaid\nflowchart LR\n A[\"start: plain attribute
self.price = 29.99\"]:::cyan\n B{\"need validation
or computation?\"}:::orange\n C[\"keep the plain attribute
no boilerplate\"]:::green\n D[\"wrap with @property
callers unchanged\"]:::teal\n\n A --> B\n B -->|no| C\n B -->|yes| D\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe diagram shows the decision tree. Most classes never leave the green branch. When a real requirement appears, the teal branch handles it without any change to the public interface. The call site never has to know which branch you took.\n\n---\n\n# When You Actually Need Getters and Setters\n\nThe Pythonic position is not \"never write accessors\". It's \"write accessors when they do real work\". A handful of situations call for going through `@property` instead of a plain attribute.\n\nThe four common reasons are validation, transformation, computation, and immutability. Each one represents a concrete behavior that a plain attribute can't provide.\n\n### Validation: Reject Bad Values at the Door\n\nA frequent reason. The setter is the natural place to enforce rules that should hold for every valid instance.\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n self.name = name\n self.price = price\n\n @property\n def price(self):\n return self._price\n\n @price.setter\n def price(self, value):\n if not isinstance(value, (int, float)):\n raise TypeError(\"price must be a number\")\n if value < 0:\n raise ValueError(\"price cannot be negative\")\n self._price = value\n\nmouse = Product(\"Wireless Mouse\", 29.99)\nprint(mouse.price)\n\ntry:\n mouse.price = -5\nexcept ValueError as e:\n print(f\"rejected: {e}\")\n```\n\n\nThe setter runs on every assignment, including the one inside `__init__`. So `Product(\"Wireless Mouse\", -5)` would also fail, which is the goal: no way for a `Product` to exist with a price that violates the rule.\n\n### Transformation: Clean the Value Before Storing It\n\nSometimes the value that comes in isn't quite the value you want stored. Trim whitespace, round to two decimal places, lowercase an email. The setter is a clean place to do that work once, in one place, so every other part of the code sees the cleaned value.\n\n\n```python\nclass Customer:\n def __init__(self, name, email):\n self.name = name\n self.email = email\n\n @property\n def email(self):\n return self._email\n\n @email.setter\n def email(self, value):\n self._email = value.strip().lower()\n\nalice = Customer(\"Alice\", \" ALICE@Example.COM \")\nprint(alice.email)\n```\n\n\nThe caller passed a messy string with mixed case and leading whitespace. The setter normalized it once during construction, and every later read returns the clean form. If the caller writes `alice.email = \" Alice@Algomaster.IO \"`, the same cleanup happens automatically.\n\n### Computation: Derive a Value From Other Attributes\n\nA read-only property with no underlying storage is what a getter does in Python. Use it when a value is a function of other attributes and you don't want to keep the two in sync by hand.\n\n\n```python\nclass Cart:\n def __init__(self):\n self.items = []\n\n @property\n def total(self):\n return sum(price * quantity for price, quantity in self.items)\n\ncart = Cart()\ncart.items.append((29.99, 2)) # mouse, qty 2\ncart.items.append((9.99, 1)) # cable, qty 1\n\nprint(f\"Cart total: ${cart.total:.2f}\")\n\ncart.items.append((14.99, 1)) # hdmi cable\n\nprint(f\"Cart total: ${cart.total:.2f}\")\n```\n\n\nNobody told `total` to refresh. It doesn't need to, because it isn't stored anywhere; each read recomputes from the current items. No risk of a stale total drifting out of sync with the actual contents.\n\n### Immutability: A Field That Can Be Read but Not Written\n\nA getter without a setter is read-only. The pattern fits fields that should be set once in `__init__` and never change afterward, like a customer ID or an order number.\n\n\n```python\nclass Order:\n def __init__(self, order_id, items):\n self._order_id = order_id\n self.items = items\n\n @property\n def order_id(self):\n return self._order_id\n\norder = Order(1001, [\"Wireless Mouse\"])\nprint(order.order_id)\n\ntry:\n order.order_id = 9999\nexcept AttributeError as e:\n print(f\"caught: {e}\")\n```\n\n\nReading works. Writing fails with `AttributeError` because there's no setter to call. The order ID is set once during construction and frozen for the life of the object.\n\n\n| Reason | When to use it | Decorator combination |\n| --- | --- | --- |\n| Validation | Reject bad values, enforce invariants | `@property` + `@.setter` |\n| Transformation | Clean, normalize, or coerce incoming values | `@property` + `@.setter` |\n| Computation | Value derived from other attributes | `@property` only |\n| Immutability | Field set once, never changed | `@property` only |\n\n\nThe full mechanics of these decorators belong in the `@property` lesson. Each row of the table represents real work a plain attribute can't do, which is what justifies the extra code.\n\n---\n\n# Read-Only Attributes Through `@property` Without a Setter\n\nThe \"immutability\" use case is worth a closer look because it shows how Python handles a common need with minimal ceremony. A property with only a getter behaves like a read-only attribute. Callers can read it normally; any attempt to assign raises `AttributeError`.\n\nThe convention is to store the real value in a private attribute (leading underscore) and expose it through the property:\n\n\n```python\nclass Customer:\n def __init__(self, customer_id, name, email):\n self._customer_id = customer_id\n self.name = name\n self.email = email\n\n @property\n def customer_id(self):\n return self._customer_id\n\nalice = Customer(1001, \"Alice\", \"alice@example.com\")\n\nprint(alice.customer_id)\nprint(alice.name)\n\nalice.name = \"Alice B.\"\nprint(alice.name)\n```\n\n\n`name` is a plain attribute and accepts reassignment. `customer_id` is a read-only property and refuses. The leading underscore on `_customer_id` is a \"this is the storage; don't touch it directly\" signal, but Python doesn't enforce privacy: a determined caller could still write `alice._customer_id = 9999`. The underscore communicates intent, not enforcement.\n\nRead-only properties pair well with two patterns. The first is identity fields that should never change after construction: customer ID, order number, account number, anything that represents identity in the domain. The second is derived values you want to expose but never accept writes for: a cart total, an order's shipping fee, a product's discounted price. Both share the same shape: a getter, no setter, and the value is settled either at construction time or computed fresh on every read.\n\nA caveat: if you make a field read-only and the storage is mutable (a list or a dict), the field itself can't be reassigned, but its contents can still be modified through the existing reference. A read-only `items` property that returns `self._items` doesn't prevent `cart.items.append(...)` from mutating the underlying list. To prevent that, return a copy or wrap the value in something immutable like a tuple.\n\n---\n\n# Validation in a Setter: A Worked Example\n\nThe setter is the natural place for any rule that should hold for every valid instance. The rules go inside the setter because that way they cover both the initial assignment in `__init__` and every later assignment from outside.\n\nA fuller example with both type and value checks:\n\n\n```python\nclass Review:\n def __init__(self, product_id, rating, comment=\"\"):\n self.product_id = product_id\n self.rating = rating\n self.comment = comment\n\n @property\n def rating(self):\n return self._rating\n\n @rating.setter\n def rating(self, value):\n if not isinstance(value, int):\n raise TypeError(f\"rating must be an int, got {type(value).__name__}\")\n if not 1 <= value <= 5:\n raise ValueError(f\"rating must be between 1 and 5, got {value}\")\n self._rating = value\n\ngood = Review(101, 5, \"Smooth and quiet\")\nprint(f\"product {good.product_id}: {good.rating} stars\")\n\ntry:\n Review(101, 7)\nexcept ValueError as e:\n print(f\"rejected: {e}\")\n\ntry:\n Review(101, \"five\")\nexcept TypeError as e:\n print(f\"rejected: {e}\")\n\ntry:\n good.rating = 0\nexcept ValueError as e:\n print(f\"rejected: {e}\")\n```\n\n\nThe setter ran four times in this snippet: once for the good review's constructor, once for the failed `Review(101, 7)` call (the constructor's `self.rating = 7` triggered the setter, which raised before any attributes were set), once for `Review(101, \"five\")`, and once for the late `good.rating = 0` assignment. In every case, the same validation rules applied. The only way to bypass them is writing directly to `self._rating`.\n\nThe convention for exception types:\n\n- `TypeError` for wrong type (\"rating must be an int\").\n- `ValueError` for right type but bad value (\"rating must be between 1 and 5\").\n- Include the offending value in the message. `\"got 7\"` is much easier to debug than `\"invalid rating\"`.\n\nWhen the setter raises, the assignment never completes, so the instance is left in whatever state it was in before. For `__init__`, that means no `Review` exists at all because the constructor itself raised. For a later assignment like `good.rating = 0`, it means `good.rating` is still the previous value (`5`).\n\nA setter call has the same overhead as any other method call, which is small but non-zero. In normal code this is irrelevant. In tight loops that read or write the same property millions of times, the overhead might show up in a profile; the workaround is to read the underlying value once outside the loop. This is a micro-optimization, not a daily concern.\n\n---\n\n# Refactoring From Direct Access to a Property\n\nPython lets you ship a class with a plain attribute today, and later swap that attribute for a property without breaking any caller. The refactor, concretely:\n\nDay one, the class is as simple as possible:\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n self.name = name\n self.price = price\n```\n\n\nDay fifteen, a teammate notices that an admin tool set a negative price and charged a customer the wrong amount. The fix is to reject negatives. The class becomes:\n\n\n```python\nclass Product:\n def __init__(self, name, price):\n self.name = name\n self.price = price # still triggers the setter\n\n @property\n def price(self):\n return self._price\n\n @price.setter\n def price(self, value):\n if value < 0:\n raise ValueError(\"price cannot be negative\")\n self._price = value\n```\n\n\nThe caller code, written on day one against the plain-attribute version, still looks the same:\n\n\n```python\nmouse = Product(\"Wireless Mouse\", 29.99)\nprint(mouse.price)\nmouse.price = 24.99\nprint(mouse.price)\n```\n\n\nEvery line of that caller code keeps working without any edit. The constructor call, the read, the write: all of them go through the property now, but the syntax at the call site is the same. The only visible difference is that an admin tool that tries to write `-5.00` to `mouse.price` now gets a `ValueError` instead of succeeding, which is the point of the refactor.\n\nThe mechanics that make this work are spelled out in the `@property` lesson: the underlying value moves from `self.price` to `self._price` (with the underscore) so the setter doesn't recurse into itself, and the property object on the class intercepts both reads and writes. The bigger picture: you don't have to choose between \"ship a clean API now\" and \"leave room for validation later\". You can do both, because the refactor is invisible to callers.\n\nThis is sometimes called the **uniform access principle**: from the outside, reading a stored value and reading a computed value should look the same. Python implements it through the property mechanism, which is why the upgrade is painless.\n\n---\n\n# Python's Philosophy: \"We're All Consenting Adults\"\n\nThe bigger context for this lesson is a phrase that comes up in Python circles: \"we're all consenting adults\". Python doesn't enforce true privacy on attributes. A leading underscore means \"treat this as private, please\", not \"you literally cannot access it\". A double leading underscore enables a naming-mangling trick that makes accidental clashes less likely in subclasses, but it doesn't lock anything down either.\n\nThe language assumes you trust the people who use your code to read the conventions and respect them. If someone reaches into your class and writes to `_internal_state`, that's their problem to manage, not yours to prevent. The philosophy trades hard guarantees for simpler code and easier debugging.\n\nThree consequences fall out of this:\n\n1. **There's no need to wrap every attribute in accessors \"for protection\".** A determined caller can bypass any wrapping you do. The protection comes from convention and code review, not from the runtime.\n2. **Read-only via `@property` is a signal, not an absolute barrier.** Code that respects the convention won't write to a property without a setter; code that ignores the convention can still do `obj._underlying = value`. The first kind of code is who you're designing for.\n3. **Documentation matters more than enforcement.** If a field is private, the leading underscore is the documentation. If a field is read-only by design, the absence of a setter is the documentation. Both are stronger guides than naming conventions in languages that pretend to enforce things.\n\nThis is a different mental model from languages that have `private` keywords and field-level visibility. Once the conventions are familiar, the code ends up with less ceremony and more substance. The classes that ship are smaller, the public APIs are clearer, and the time that would have gone to getter/setter boilerplate goes into actual logic.\n\n---\n\n# Advanced: `__getattr__` and `__setattr__` for the Edge Cases\n\n`@property` handles the common needs: a specific attribute with specific rules. For the rare cases where you want to intercept every attribute access on a class, two dunder methods exist: `__getattr__` for reads and `__setattr__` for writes. This is the heavy machinery, and most code never needs it.\n\n`__getattr__` is called only when normal attribute lookup fails. If the attribute exists on the instance or the class, Python doesn't call `__getattr__` at all. The method runs as a fallback, which makes it useful for proxying attribute access to some underlying store:\n\n\n```python\nclass Settings:\n def __init__(self, **defaults):\n self._data = dict(defaults)\n\n def __getattr__(self, name):\n # only called when normal lookup misses\n if name in self._data:\n return self._data[name]\n raise AttributeError(f\"no setting named {name!r}\")\n\nconfig = Settings(theme=\"dark\", page_size=20)\nprint(config.theme)\nprint(config.page_size)\n\ntry:\n print(config.missing)\nexcept AttributeError as e:\n print(f\"caught: {e}\")\n```\n\n\n`config.theme` first tries the normal lookup (instance dict, then class), finds nothing, and falls back to `__getattr__`, which checks the `_data` dict and returns the value. Same for `page_size`. `config.missing` also misses, the dict doesn't have a `missing` key, and the method raises `AttributeError` to signal \"this attribute doesn't exist\".\n\n`__setattr__` is the opposite, and it's much trickier because it runs on **every** attribute assignment, including the ones inside `__init__`. Forgetting that fact leads to immediate infinite recursion:\n\n\n```python\n# what's wrong with this code?\nclass Logger:\n def __setattr__(self, name, value):\n self.log = f\"set {name} = {value}\" # recurses forever\n super().__setattr__(name, value)\n\nlogger = Logger()\n```\n\n\nThe line `self.log = f\"set {name} = {value}\"` inside `__setattr__` is itself an attribute assignment, which calls `__setattr__` again, which tries to set `self.log` again, and so on. Python raises `RecursionError` after about a thousand levels. The fix is to use `super().__setattr__` or `object.__setattr__` to bypass the override:\n\n\n```python\nclass Logger:\n def __init__(self):\n super().__setattr__(\"_log\", [])\n\n def __setattr__(self, name, value):\n super().__setattr__(\"_log\", self._log + [f\"set {name} = {value}\"])\n super().__setattr__(name, value)\n\nlogger = Logger()\nlogger.user = \"Alice\"\nlogger.action = \"login\"\nprint(logger.user)\nprint(logger.action)\nprint(logger._log)\n```\n\n\nEvery assignment now goes through `__setattr__`, which records the event and then delegates to the default mechanism via `super().__setattr__`. The `_log` attribute is itself set via `super().__setattr__` to avoid the recursion trap.\n\nThese two methods are powerful but easy to misuse. The general advice: use `@property` first. Only when you need to intercept attributes whose names aren't known in advance (proxies, lazy loaders, configuration objects, ORM-like classes), `__getattr__` and `__setattr__` fit. For everything else, named properties are simpler, more readable, and less error-prone.\n\n`__setattr__` runs on every write. A class with `__setattr__` defined pays the method-call overhead on every assignment, including the ones inside `__init__`. That's usually fine, but it's measurable in tight loops and is a reason to keep the override minimal.","pageType":"python"}

Getters & Setters

Get Premium