self, __init__, and the dunder protocols

Python classes look familiar enough to lull you and differ in three places that matter: the explicit self, the absence of any access control, and the fact that most of the interesting behaviour comes from the dunder protocols rather than from inheritance.

The shape

class RetryPolicy:
    MAX = 10                                  # class attribute. Shared by all instances.

    def __init__(self, attempts: int = 3, backoff: float = 1.5) -> None:
        self.attempts = attempts              # instance attributes. Created here.
        self.backoff = backoff
        self._calls = 0                       # leading underscore: internal by convention

    def delay_for(self, n: int) -> float:     # a method. self is the receiver.
        return self.backoff ** n

    @property
    def is_aggressive(self) -> bool:          # a computed attribute, read as p.is_aggressive
        return self.attempts > 5

    @staticmethod
    def default() -> "RetryPolicy":           # no self. Just a namespaced function.
        return RetryPolicy()

    @classmethod
    def from_config(cls, cfg: dict) -> "RetryPolicy":   # cls is the class, not the instance
        return cls(attempts=cfg["attempts"])

RetryPolicy(attempts=5) constructs it. There is no new.

__init__ is not the constructor, exactly

__init__ initialises an object that already exists. The actual constructor is __new__, which you will essentially never write. The distinction matters once: __init__ must return None, and returning anything else from it is an error.

self is a real parameter

It is not a keyword and the interpreter does not inject it. instance.method performs an attribute lookup that returns a bound method with the instance already supplied as the first argument, and the parameter list has to have somewhere to receive it.

Two consequences that are worth more than the trivia:

• You must write self.x for every instance attribute, everywhere, including inside the class’s own methods. There is no implicit receiver. Forgetting it creates a local variable that vanishes at the end of the method, silently.
• A bound method keeps its receiver. callback = obj.handle and then calling callback() works exactly as you would hope. This is the JavaScript this-binding footgun simply not existing.

Attributes are created by assignment

There is no field declaration list. An attribute exists once something assigns to it, which is normally in __init__ but need not be.

p = RetryPolicy()
p.atempts = 9        # typo. Creates a NEW attribute. No error at all.

Nothing catches that at runtime. A typechecker will, which is one of the stronger arguments for running one, and __slots__ will, at the cost of some flexibility. This is the clearest case in the language where the safety you are used to has to be added rather than assumed.

Nothing is private

self.public      # anyone
self._internal   # a request not to touch it. Nothing enforces this.
self.__mangled   # rewritten to self._ClassName__mangled. Still reachable.

A single leading underscore is the real convention and the only one you should use. It means this is not part of the interface, and every Python developer reads it that way. The double underscore triggers name mangling, which exists to stop a subclass accidentally colliding with a base class’s internals, not to prevent access. Describing it as private is wrong, and doing so in a code review will get you corrected.

Worth noting that TypeScript’s private is also erased at runtime, so the honest comparison is that both languages are relying on tooling. Python simply never pretended otherwise.

Dunders are the actual interface system

This is the idea worth taking from the whole lesson. Python puts operations in functions and operators that dispatch to double-underscore methods on your type, rather than in differently-named methods per class.

There is no implements and no interface declaration. Implementing the method is the entire act of conforming, which is structural typing enforced at the moment of use rather than at compile time. It is why the standard library composes as well as it does, and it is the mechanism behind three of the four idioms in module 4.

Implement __repr__ before __str__

__repr__ is the developer-facing one, and it is what the REPL prints, what a debugger shows, and what a list of your objects shows for each element. __str__ is the human-facing one and falls back to __repr__ when absent. The reverse is not true, so a class with a lovely __str__ and no __repr__ still gives you a debugging session full of memory addresses.

def __repr__(self) -> str:
    return f"RetryPolicy(attempts={self.attempts}, backoff={self.backoff})"

In practice you will write this by hand rarely, because dataclasses generate it for you. That is module 3.

Inheritance, briefly

class BackoffPolicy(RetryPolicy):
    def __init__(self, attempts: int, jitter: float) -> None:
        super().__init__(attempts=attempts)
        self.jitter = jitter

super() takes no arguments in modern Python and finds the next class in the resolution order. Multiple inheritance is legal and is genuinely used for mixins, which is why the resolution order has a name and an algorithm. You do not need to learn it today; you need to recognise that a class with three bases is doing something deliberate rather than something broken.

Abstract base classes exist in abc, and you will meet them in frameworks. typing.Protocol is the more modern and much more Pythonic answer to the same problem, and it gets a proper look in module 3.

Where this goes

That is the language. You can now read a Python file end to end and know what every line is doing.

Module 2 is the part that actually changed since you last looked: the toolchain. It is one tool, it is genuinely excellent, and the reason it exists takes about five minutes to explain properly.