Building your own kinds of thing

You write class BankAccount: and then, indented inside it, the functions this kind of thing can do. Those functions are called methods.

The special method __init__ runs automatically whenever you make a new object, and its job is to set up the starting information. The double underscores mean Python calls it for you rather than you calling it by name.

Every method takes self as its first parameter. self means “the particular object this was called on”. When you write self.balance = 0 inside __init__, you are storing a balance on this one account, separate from every other account. When you later write account.deposit(50), Python passes that account in as self automatically — which is why you never pass it yourself.

self feels arbitrary right up until the moment it does not. The thing that makes it click, for most people, is making two objects from the same class and watching them hold different values completely independently.

Without classes you might keep a balance in one variable and write separate functions that change it. Nothing stops some other part of the program setting that balance to minus a million.

With a class, the balance lives inside the object and the only way to change it is through methods you wrote — a withdraw method that refuses to overdraw, for instance. The rule and the data sit together.

That is the whole justification. Not that objects are elegant, but that they give you one place to enforce what is true about a thing. As programs grow, that is what stops them becoming impossible to change safely.

print(my_account) with no __str__ gives you something like <__main__.BankAccount object at 0x7f9>. That is a memory location, and it tells you nothing.

Define __str__ to return a piece of text, and printing shows that instead. There is a sibling called __repr__ meant for programmers debugging, which is what shows up when an object appears inside a list.

This is a small thing that pays for itself immediately: when you get to linked lists and trees, being able to print a structure and actually read it is the difference between debugging in minutes and debugging for an afternoon.

A Library object can hold a list of Book objects. Nothing new is needed for this: an object is just a value, so it can be stored like any other value.

Now make an object that holds a reference to another object of the same class. A Node with a value, and a next that points at another Node. Chain three of them together and you have built a linked list, weeks before anyone calls it that.

A tree node holds references to two children instead of one next. A graph vertex holds references to several neighbours. Every structure ahead is a variation on this one move.

This is why the roadmap puts classes immediately before data structures rather than treating them as an optional extra. If composition is comfortable, the rest is variations on a theme. If it is not, the rest is memorisation — and memorised structures do not survive contact with a real problem.

Every recursive function needs two things. A base case: the simplest situation, answered directly without calling itself. And a recursive case: the function calling itself on something smaller, moving towards that base case.

Factorial is the standard first example. The factorial of 5 is 5 times the factorial of 4. The factorial of 1 is just 1 — no further calls. Each step is smaller than the last, and there is a floor to hit.

A missing or unreachable base case causes a RecursionError, which is Python telling you the calls piled up without ever finishing. Every call occupies real space while it waits, in a pile called the call stack, and Python stops you at about a thousand deep as a safety measure.

You are not trying to master recursion here. You are trying to stop finding it frightening, because week 13 covers it properly and week 20 onwards assumes it completely.