Object Construction: __new__ vs __init__

Python splits object construction into two named steps, and most interview confusion comes from calling the second one "the constructor". The call `MyClass(a, b)` dispatches to the type of `MyClass` — its metaclass, normally `type` — so what actually runs is `type.__call__`, which behaves like this: ```python obj = MyClass.__new__(MyClass, a, b) if isinstance(obj, MyClass): type(obj).__init__(obj, a, b) return obj ``` **`__new__` is the creator.** It receives the class as its first argument, conventionally named `cls`, and it is responsible for producing an object and returning it. The base implementation, `object.__new__`, is what actually allocates the instance and gives it its type; a custom `__new__` almost always ends by delegating to it with `return super().__new__(cls)` and then, if needed, adjusting or replacing the result. Whatever `__new__` returns is what the caller gets — the protocol offers no later opportunity to substitute a different object. **`__init__` is the initializer.** It receives an already-created instance as `self` and exists purely for side effects on it: binding attributes, validating arguments, registering the object. Its own result is discarded and must be `None`. It runs after `__new__`, and it is skipped entirely when the object `__new__` returned is not an instance of the class being called — that is how a `__new__` that returns a completely foreign object bypasses initialization. **`__new__` is implicitly a static method.** Class creation special-cases the name: even though it is written as a plain `def` in the class body, it is wrapped as a static method automatically, so `@staticmethod` is unnecessary (and harmless). The practical consequence is that no class is bound for you — the class must be passed explicitly. That is why `cls` is an ordinary first parameter and why the delegation is `super().__new__(cls)` and not `super().__new__()`. A candidate who writes `def __new__(self, ...)` has usually not internalized that the first argument is the class about to be instantiated, which matters because a subclass call arrives with the *subclass* in `cls`; allocating with the hard-coded base class instead of `cls` silently breaks every subclass. **Both steps see the same arguments.** `type.__call__` forwards the call's positional and keyword arguments to both methods, so their signatures have to be compatible. Accepting `*args, **kwargs` in whichever one does not care about them is the usual way to keep that true. There is one asymmetry worth memorizing, because it is the single most common runtime error when people first write `__new__`: `object.__new__` accepts only the class. Writing `return super().__new__(cls, name)` raises `TypeError: object.__new__() takes exactly one argument (the type to instantiate)`. Arguments reaching `object.__new__` are tolerated *only* when `__new__` was not overridden and `__init__` was — the ordinary case — and `object.__init__` mirrors that rule in the other direction. If a class overrides neither and is called with arguments, the error is `takes no arguments`. **When to override which.** The default answer is `__init__`: it covers essentially all ordinary classes, and reaching for `__new__` to do attribute setup is a smell that makes subclassing and pickling harder for no gain. Override `__new__` when creation itself is the thing you need to control: * **Subclassing an immutable built-in** such as `int`, `str` or `tuple`. The value is fixed while the object is being made, so it must be handed to `int.__new__` / `str.__new__` / `tuple.__new__`; `__init__` arrives too late to change it. * **Interning, caching or pooling.** Returning an existing instance for a repeated key — the mechanism behind singletons and flyweights — is only possible where the object is chosen, and that is `__new__`. * **Returning a different class.** A base class can inspect its arguments and allocate a concrete subclass instead, giving dispatch at construction time. * **Returning a foreign object entirely**, which additionally suppresses `__init__`. **What the split costs.** A custom `__new__` becomes part of the class's contract with the rest of the runtime. Copying and unpickling rebuild objects by calling `cls.__new__(cls)` directly rather than by calling the class, so a `__new__` with required parameters raises there unless the class supplies the arguments through `__getnewargs__`. Caching in `__new__` means `__init__` may run repeatedly on the same object. And error handling is subtler: an exception in `__new__` means no object exists at all, while an exception in `__init__` means an allocated object is abandoned half-built. The compact framing to give an interviewer: `__new__` decides *which object exists* and returns it; `__init__` decides *what that object contains* and returns nothing. Everything else — the implicit static method, the explicit `cls`, the skipped initializer, the immutable-subclass rule — follows from that one distinction.