Module 4 ended with a clear diagnosis: at Papyrus, data lives in one dictionary (catalog) and behavior lives somewhere else (papyrus_utils.py). final_price() trusts you to pass it the right number; find_book() trusts the dictionary to have the expected shape. Nothing ties the two halves together. Object-oriented programming (OOP) solves exactly that: a class is a mold that packages data and behavior into a single named unit, and every object created from that mold carries its data with it and knows how to operate on it. In this lesson you will build Papyrus's Book class: each book will stop being a dictionary entry and become an object that calculates its own member price.

1. From dictionaries to classes: why make the leap
2. Defining a class with class and __init__
3. self: the object talks about itself
4. Instance attributes vs class attributes
5. Methods: behavior that travels with the data
6. Papyrus's complete Book class
7. Several objects from the same mold
8. Common mistakes and tips
9. Exercises with solutions

Remember how the catalog ended up after the big refactor in 04-03:

And how a price gets calculated, from papyrus_utils.py:

It works, but look at the seams:

• Nothing guarantees the structure: if someone writes {"price": "12,50"}, no part of the program complains until it blows up somewhere else.
• The knowledge is scattered: to find out what you can do with a book you have to dig through papyrus_utils.py.
• The function and the data don't know each other: final_price() accepts any number; it has no idea it works with books.

A class inverts the relationship: instead of functions that receive data, you have data that carries its functions built in.

The minimal syntax:

Line-by-line breakdown:

• class Book: — declares the class. By PEP 8 convention, class names use CapWords (Book, EBook), unlike functions and variables (final_price, total_stock).
• The docstring works just like it did for functions in 03-01: it documents what the class is for.
• __init__ is the initializer: a special method that Python runs automatically every time you create an object. It receives the initial data and stores it.
• self.title = title — creates an instance attribute: a variable that belongs to that specific object, not to the class in general.

To create an object (an instance), you call the class as if it were a function:

Notice that you do not pass self when calling: you write Book("The Odyssey", 12.50, 4) with three arguments, and Python places the freshly created object into self for you.

self is the parameter that receives the object itself — the one currently being worked on. When Ana writes odyssey.member_price(), Python translates it internally into Book.member_price(odyssey): the object travels as the first argument.

• Inside in_stock, self.stock means "the stock of this book".
• If odyssey.stock is 4 and faust.stock is 0, odyssey.in_stock() returns True and faust.in_stock() returns False — same code, different data, because self points to a different object on each call.

self is not a reserved word: it is a universal convention. You could name it something else, but no Python programmer ever does. Always respect it.

The VAT on books and the member discount are the same for every book at Papyrus. It makes no sense to store them in each object: they are class attributes, shared by all instances.

When you access odyssey.BOOK_VAT, Python looks in the object first; if it doesn't find it there, it climbs up to the class. That's why it works from both sides. Notice how the constants that lived loose back in module 1 (STORE_NAME, BOOK_VAT) now find a natural home inside the class they conceptually belong to.

A method is a function defined inside a class. Papyrus's pricing formula (base × (1−discount) × (1+VAT), rounded to 2 decimal places) stops living in papyrus_utils.py and becomes knowledge the book itself carries:

Compare the two calls:

The result is identical (12.35 EUR), but the second style can't grab the wrong data: the method always operates on its own book's price.

And in action, with the four canonical titles:

The prices match exactly what Luis (member LUIS-001) has been paying since module 4: the logic is the same — it has just moved house.

The key distinction of the day: the class is the mold (written once); each instance is an independent object with its own values.

Every object has its own identity: modifying faust.stock doesn't affect odyssey.stock (none of the aliasing traps from 04-01, because they are distinct objects from the moment they are created). You can check the type of any object with type():

One detail you may already have spotted if you've tried print(odyssey):

It comes out "ugly": Python doesn't know how to display a Book as readable text, so it shows its memory address. There's an elegant fix, but it belongs to the magic methods of lesson 05-05. Until then, print specific attributes (book.title) whenever you need readable output.

• Forgetting self in the method definition. def member_price(): without self raises TypeError: member_price() takes 0 positional arguments but 1 was given when called, because Python always passes the object as the first argument. Every instance method starts with self.
• Forgetting self. when using an attribute. Inside a method, plain price is a nonexistent local variable (NameError); the object's attribute is self.price. Revisit variable scope from 03-01: the rules haven't changed.
• Writing Book() with no arguments when __init__ requires them: TypeError: __init__() missing 3 required positional arguments. The parameters of __init__ work exactly like those of any function (03-02), including default values: def __init__(self, title, price, stock=0) would allow creating books with no initial stock.
• Confusing the class with the instance. Book.member_price() fails because there's no object to operate on; odyssey.member_price() works. The class is the blueprint; the instance is the building.
• Using a mutable class attribute as a per-instance value. reservations = [] in the class body would be shared by every book — the same trap as the mutable default argument in 03-02. Per-object lists and dictionaries are always created in __init__ with self.reservations = [].
• Tip: start every class by answering two questions: what data does it describe? (attributes) and what does it know how to do with it? (methods). If a method never touches self, it should probably be a plain function outside the class.

Papyrus manages members like Luis (LUIS-001) and Marta (MARTA-002). Create a Member class with instance attributes name and code, and a method greeting() that returns "Hello, Luis (member LUIS-001)". Create the members Luis, Marta (MARTA-002) and Pau (PAU-003) and print all three greetings with a loop.

Add a method sell(units) to the Book class that subtracts units from the stock only if there is enough, returning True if the sale went through and False if it didn't. Test it: Julia wants 2 copies of "The Odyssey" (stock 4) and Omar wants 1 "Faust" (stock 0).

Add a class attribute total_books = 0 to Book that gets incremented by 1 inside __init__ every time a book is created (hint: Book.total_books += 1). Create the four catalog books and verify that Book.total_books equals 4.

Solution 1:

Each object stores its own name and code; the greeting() method is the same for all three, but self makes each one speak about itself.

Solution 2:

Notice how the check protects the data: the stock can never go negative as long as everyone uses sell(). Making sure nobody can bypass it is precisely the subject of encapsulation (05-04).

Solution 3:

The counter lives in the class, which is why every instance shares it and every creation increments it. If you wrote self.total_books += 1, you'd create an instance attribute that shadows the class one — a classic mistake.

Today you joined together what module 4 left apart: the Book class packages the data (title, price, stock) with its behavior (member_price(), in_stock()) in a single unit. You've learned that class defines the mold, __init__ initializes each object, self lets each instance speak about itself, and that instance attributes (different per object) coexist with class attributes (BOOK_VAT, MEMBER_DISCOUNT, shared by all). Every Papyrus book now calculates its own member price: 12.35 EUR for "The Odyssey", 20.75 EUR for the sold-out "Faust". But Ana's shop doesn't sell only books: there are also magazines and, soon, ebooks with no physical stock. Will we have to copy and paste the Book class three times? Not at all: the next lesson introduces inheritance, the mechanism by which a Product class will share what's common while each kind of item adds only what makes it different.