Polymorphism closed with a warning: nothing stops anyone from writing odyssey.price = -5 or faust.stock = -3, and from that moment on every Papyrus calculation lies. In 05-01 you wrote sell() precisely so the stock could never go negative... but anyone can bypass the method and touch the attribute directly. Encapsulation is the principle that fixes this: each object protects its internal data and only allows changes through controlled channels, so that its invariants — the rules that must always hold, such as "stock is never negative" — cannot be broken, even by accident. Python solves it in its own way: no real locks, just clear conventions and an elegant tool called a property.

1. What encapsulating means and why it matters
2. The underscore convention: _protected
3. Double underscore and name mangling: __private
4. The problem with Java-style getters/setters
5. @property: computed and validated attributes
6. The setter: validating without changing the interface
7. Product, armor-plated: the final version
8. Common mistakes and tips
9. Exercises with solutions

Encapsulating means separating the what (the public interface: final_price(), sell()) from the how (the internal details: which attribute the stock lives in, how it's validated). The benefits are concrete:

• Business invariants guaranteed: at Papyrus, stock is never negative, price is never negative, a member code always follows the NAME-NNN format. If the object watches over its own data, no part of the program can corrupt it.
• Freedom to change on the inside: if tomorrow stock goes from a single integer to a per-warehouse breakdown, the rest of the code never notices as long as in_stock() keeps answering the same way.
• Less room for error: whoever uses the class only sees what they're supposed to use.

That said, an important cultural difference: Python has no truly private attributes (like private in Java or C#). Its philosophy is summed up in the phrase "we're all consenting adults": the language signals what is internal and trusts you to respect it.

A leading underscore marks an attribute or method as internal: "don't touch this from the outside; it may change without notice". It's only a convention — Python doesn't enforce it — but the whole community respects it.

The last line works, and that's the whole point: _purchases is a traffic sign, not a wall. Good linters and code reviewers will flag it, and that social contract is surprisingly effective.

Two leading underscores (without two trailing ones) trigger name mangling: Python internally renames the attribute to _ClassName__attribute.

Points you need to be clear on:

• It is not real security: anyone who knows the trick gets in with _Member__code. It's surface-level concealment, not encryption or protection.
• Its genuine purpose is to avoid name collisions in inheritance: if Product uses __counter and a subclass defines its own __counter, mangling keeps them apart (_Product__counter vs _Book__counter).
• Day to day, the Python community prefers the single underscore. Reserve __private for classes designed to be inherited by strangers.

In languages with strict privacy, the classic recipe is: private attribute + get method + set method. Ported literally to Python it looks like this:

It does validate, yes, but at the cost of an ugly interface and of breaking all existing code that did book.price. Python has something better.

A property is a method disguised as an attribute: you read it as book.price (no parentheses), but under the hood it runs code. It's a standard-library decorator (decorators in general are covered in module 8; for now it's enough to know how to use this one).

Without a setter, the property creates a read-only attribute: nobody can slap a price on by brute force anymore. Properties are also useful for computed attributes that aren't stored anywhere:

To allow assignment with control, you add the setter with @name.setter:

Now validation is automatic and the syntax stays natural:

raise ValueError(...) stops the program with a clear message; you already used the idea when validating inputs, and module 7 will teach you to catch these errors with try/except. What matters today: the object rejects the invalid data at the exact moment it tries to get in.

The "breaks code?" row hides the big strategic advantage: you can start with a plain public attribute (self.price) and turn it into a property years later, when validation becomes necessary, without touching a single line of client code. That's why in Python nobody writes preventive getters/setters "just in case", as Java orthodoxy demands.

Let's apply all of it to the base class of the hierarchy (05-02). Invariants to protect: price ≥ 0, stock a non-negative integer.

Two golden subtleties in this code:

• __init__ assigns to self.price, not self._price: that way validation also applies at construction time. Product("Ghost", -3, 1) fails immediately, which is exactly where it should fail.
• Subclasses inherit the armor for free: Book, Magazine and EBook don't change a single line, and their prices and stocks are protected, because their super().__init__(...) calls flow into these setters.

• Infinite recursion in the property: writing return self.price inside the getter of price (or self.price = value in its setter) calls the property over and over until RecursionError. Inside the getter/setter, always use the internal attribute self._price.
• Validating in the setter but assigning to self._price in __init__: the object is born unvalidated. In __init__, assign to the public name (self.price = price) so the setter kicks in from second one.
• Believing that __private protects sensitive data: name mangling is bypassed with obj._Class__attribute; it's not a security mechanism, just name hygiene for inheritance.
• Writing preventive get_x()/set_x() getters/setters for everything: it's noise inherited from Java. Public attribute first; property when (and only when) you need to validate or compute.
• Forgetting the @property above the getter and leaving only @price.setter: NameError, because the setter is defined based on the existing property. The order is: @property first, @name.setter after.
• Tip: decide what constitutes the public interface (what you document: title, price, stock, sell(), final_price()) and mark everything else with _. A class with few doors is a class that's easy to reason about and to maintain.

At Papyrus, a product's title must not change once created (it's its identity in the catalog). Turn title into a property without a setter that also validates in __init__ (via an internal method or the stored value itself) that it isn't an empty string after strip(). Verify that odyssey.title = "Something else" fails and that Product(" ", 5.0) raises ValueError.

Create the Member class with a public name and a code property with getter and setter. The setter must validate Papyrus's NAME-NNN format: the left part alphabetic and uppercase, a hyphen, and three digits (revisit split(), isalpha(), isdigit(), isupper() from 04-05). "LUIS-001" and "MARTA-002" must pass; "luis-001", "LUIS001" and "LUIS-1" must raise ValueError.

Add to Product an internal attribute _reservations (a list) and the methods reserve(customer) and serve_reservation(). reserve is only allowed when there is NO stock (if there is, it should return the notice "In stock: buy directly"); serve_reservation pops the first customer off the list (order of arrival) or returns None if there are no reservations. Simulate: Faust with stock 0, Julia and Omar reserve, stock arrives, Julia gets served.

Solution 1:

Without a setter, the property is read-only: the product's identity is sealed at birth.

Solution 2:

It's the same rule as is_valid_member() from papyrus_utils.py, but now it lives where it belongs: in the object that stores the data, impossible to forget.

Solution 3:

The _reservations list is never manipulated from outside: the order of arrival is guaranteed by construction. (For long queues, remember that deque from 04-06 does popleft() in constant time; here pop(0) is enough.)

Encapsulation has closed the crack that polymorphism left exposed: _internal flags what shouldn't be touched, __private adds name mangling (name hygiene, never real security), and @property with its @setter delivers the best of both worlds — the natural syntax of an attribute with the validation of a method. Papyrus's Product class no longer accepts negative prices or impossible stocks, and all its subclasses inherit the armor without changing a line. With data joined to its behavior (05-01), organized into a hierarchy (05-02), polymorphic (05-03) and protected (05-04), the only thing missing is for your objects to speak Python's native language: for print(odyssey) to show something worthy, for sorted(catalog) to sort books without key=, for book in cart to just work. All of that is granted by the magic methods, and with them we'll finally settle the debt pending since 05-01: the "ugly" print. That's the next lesson.