What does a metaclass's `__call__` control that a class's own `__new__` cannot?

The mechanism follows from one fact: **a class is an object, and calling an object calls its type's `__call__`**. So `Timetable("ZZ", 7)` is `type(Timetable).__call__(Timetable, "ZZ", 7)`. If `Timetable` has an ordinary metaclass, that is `type.__call__`, whose behaviour is roughly: 1. call `cls.__new__(cls, *args, **kwargs)` to get an object; 2. if the returned object is an instance of `cls`, call `type(obj).__init__(obj, *args, **kwargs)`; 3. return the object. Everything a metaclass `__call__` can do that `__new__` cannot follows from owning that whole sequence rather than one step inside it. ## The re-initialisation trap The classic interning attempt puts a cache in `__new__`: ```python def __new__(cls, key): if key in cls._seen: return cls._seen[key] ... ``` It returns the shared object — and then step 2 fires, because the returned object *is* an instance of `cls`, so `__init__` runs on it again with the new arguments. Any state built up on that object is silently reset on every subsequent call. Worse, the arguments a caller passes the second time may differ, so the shared object quietly mutates under everyone holding it. Move the cache into the metaclass's `__call__` and you decide whether `super().__call__(...)` — the `__new__`/`__init__` pair — runs at all. ## Where this actually pays off Consider a flight-schedule differ that parses published timetables and compares revisions. Parsing one is expensive: a cold start of about 45 seconds before the first comparison can be produced. The comparison rules ask for `Timetable(carrier, revision)` in dozens of places, and each request must yield the same parsed object. A caching metaclass keys instances on the constructor arguments and returns the existing one, so parsing happens once per `(carrier, revision)` regardless of how many call sites ask. It also gives you a place to *canonicalise* before caching. A clock-skew artefact — the same published revision arriving with timestamps a second or two apart from two upstream feeds — would otherwise produce two cache keys and two parsed objects that then compare as different. Normalising the key inside `__call__`, before any object is allocated, is the natural fix; `__new__` cannot get in front of that because by then the call has already been dispatched to the class. Other legitimate uses: rejecting invalid constructor arguments with a domain error before allocation; returning an instance of a *different* class (a factory that picks a subclass by argument); attaching cross-cutting bookkeeping after `__init__` returns, in one place, for every subclass. ## Cost, and why this is a differentiator rather than a gate A metaclass `__call__` is invisible at the call site. A reader sees `Timetable("ZZ", 7)` and reasonably assumes a fresh object. Debuggers step past it. Type checkers model the constructor from `__init__`, so a `__call__` that returns something else is a lie to static tooling. And the metaclass is inherited: every subclass gets the interception, whether or not it wants it. The caching itself has an operational cost people forget. A dict on the class holds strong references for the life of the process, so it is an unbounded leak keyed by whatever arguments callers happened to pass. If the population of keys is unbounded, use weak references, an explicit bounded cache, or an explicit factory function that callers can see. Cache keys must also be hashable and canonical, which rules the pattern out for constructors taking mutable arguments. ## The honest alternative Much of what people build metaclass `__call__` for is better expressed as a plain module-level factory function — `get_timetable(carrier, revision)` — with an ordinary cache inside it. It is visible, testable, mockable, and it lets a caller who genuinely wants a fresh object still call the class directly. Reach for `__call__` when the interception must be *unavoidable* — because third-party code calls the class directly and you cannot change those call sites — and say so when you propose it. The interviewer is checking two things: that you know `Klass()` dispatches to the metaclass rather than to `Klass.__call__`, and that you know why the naive `__new__` cache re-runs `__init__`. Everything else is judgement about whether the magic is worth it.