Why does a `__new__`-based singleton re-run `__init__` on every call, and how do you stop it?

The singleton written with `__new__` is one of the most common patterns in Python code and one of the most commonly broken, because it half-controls a two-step protocol. Calling a class runs `type.__call__`, which calls `__new__` for an object and then, **if that object is an instance of the class**, calls `__init__` on it with the same arguments. A caching `__new__` returns the stored instance — which is, of course, an instance of the class — so the guard passes and the initializer runs again. The object's identity is shared; its state is re-set on every call. **What that looks like in production.** Consider a client that runs an ETL export into a warehouse. Start-up code creates it with a long timeout because the warehouse takes about 45 seconds to come out of a cold start; a request-handling module elsewhere later writes a bare `ExportClient()` to "get the shared client". That second call re-enters `__init__`, which reassigns the default 5-second timeout onto the very same object the first module tuned. The failure is an intermittent export timeout: it depends entirely on whether the bare call happened to run before the next cold-start export, so it survives every test, reproduces on no developer machine, and looks like a network problem. Nothing raises, nothing logs, and the object is correct by identity while wrong by state — which is exactly why this is a senior question. The diagnostic instinct worth demonstrating is to stop trusting the singleton's state and print or log the configuration at use time rather than at construction time; the value flipping between calls names the cause immediately. ```python class ExportClient: _instance = None def __new__(cls, timeout=5.0): if cls._instance is None: cls._instance = super().__new__(cls) return cls._instance def __init__(self, timeout=5.0): self.timeout = timeout # runs on every call tuned = ExportClient(timeout=45.0) ExportClient() print(tuned.timeout) # 5.0 - the tuned value is gone ``` **Fix one, and the best one: do not use `__new__`.** A module-level instance created once at import, or a factory function that builds and returns a cached object, expresses "one shared object" without overloading construction. Calling the class then always means "make me one", which is what every reader expects it to mean, and the shared object can be replaced in tests by passing a different one in. Hiding sharing inside `__new__` makes `ExportClient()` lie about what it does. **Fix two: put the setup in `__new__`.** If the class must remain the entry point, do the configuration where the object is chosen, and define no `__init__` at all. Then there is no second step to re-run. ```python import threading class ExportClient: _instance = None _lock = threading.Lock() def __new__(cls, timeout=5.0): with cls._lock: if cls.__dict__.get("_instance") is None: obj = super().__new__(cls) obj.timeout = timeout cls._instance = obj return cls._instance ``` **Fix three: make `__init__` idempotent.** Guard the body with a flag set on first run (`if getattr(self, "_ready", False): return`). It works, but it leaves a class whose arguments are silently ignored on every call after the first — an API that quietly discards what the caller asked for. Raising instead, when a later call passes arguments that contradict the configured ones, is usually more honest than ignoring them. **Three details that separate a strong answer.** First, **thread safety**: `if cls._instance is None` followed by an assignment is two separate steps, and the interpreter may switch threads between them, so two callers can each create an instance. A `threading.Lock` around the check-and-create, or simply creating the object at import time, closes that window; the GIL does not, because it guarantees nothing about a sequence of operations. Second, **subclasses**: `cls._instance` resolves through the class hierarchy, so once the base has an instance, every subclass call finds it and returns an object of the wrong class. Reading `cls.__dict__.get("_instance")` — or keying a dictionary by `cls` — gives each class its own slot. Third, **reconstruction paths**: copying and unpickling rebuild an object with `cls.__new__(cls)` and no call arguments, so a `__new__` that requires them raises there, and any invariant the pattern claims to enforce has to survive those paths too. **The strategic point.** A singleton is process-global mutable state. It makes tests order- dependent, hides a dependency that would be obvious as a parameter, and — as the export example shows — turns a configuration mistake into an intermittent runtime failure far from its cause. Reaching for it because "there should only be one" is usually the wrong reason; passing the one object explicitly to whatever needs it costs a parameter and removes the whole class of bug.