Python OOP — new, call, and the Singleton Pattern Explained

The Story That Explains These Three Ideas

__new__ vs __init__ — The Full Lifecycle

When you write Person("Alice", 30), two methods run in order. Almost every Python class only needs __init__ — Python's default __new__ handles the creation invisibly. Understanding both is what unlocks singletons, immutable subclasses of built-in types, and metaclasses.

class Person:
    def __new__(cls, *args, **kwargs):
        print(f"  [__new__] creating a new Person object")
        instance = super().__new__(cls)      # let object create it for us
        return instance                          # MUST return the new object

    def __init__(self, name, age):
        print(f"  [__init__] filling in name={name!r}, age={age}")
        self.name = name
        self.age  = age

print("Creating Alice:")
alice = Person("Alice", 30)
print()
print("Creating Bob:")
bob = Person("Bob", 25)

Animated Diagram — The Two-Step Object Creation

Follow Person("Alice", 30). Python fires __new__ first — it produces a bare, unnamed object. Then it fires __init__ on that same object — filling in name and age. The finished object is what your variable receives.

When Do You Actually Override __new__?

99% of Python classes never touch __new__. The default handles it. You reach for it only when you need to control which object is returned, or subclass an immutable built-in type.

__call__ — Making an Instance Callable

Functions are callable — len(), print(), your own calculate(). Instances are usually not callable. Defining __call__ changes that: your instance can now be invoked with () just like a function.

class Multiplier:
    def __init__(self, factor):
        self.factor = factor

    # ── This makes the instance callable ──
    def __call__(self, x):
        return x * self.factor


double = Multiplier(2)
triple = Multiplier(3)

# Instances now behave like functions
print(double(10))    # 20   ← calls double.__call__(10)
print(triple(10))    # 30   ← calls triple.__call__(10)

# They can even be passed anywhere a function is expected
print(list(map(double, [1, 2, 3])))   # [2, 4, 6]

# They remain OBJECTS — you can inspect and mutate state
print(double.factor)          # 2
double.factor = 5
print(double(10))            # 50   ← same instance, new behaviour

Animated Diagram — obj() Becomes obj.__call__()

Why Callable Classes Instead of Just Functions?

Common patterns that benefit from __call__:

• Configured functions — a validator with rules bound at construction (Validator(min_length=8)), then called as validator("input")
• Counters and accumulators — instance carries the running total between calls
• Decorators as classes — @Retry(max_attempts=3) — the decorator's __call__ wraps the function
• Pipelines / transforms — Pipeline(steps) then pipeline(data)
• Fluent APIs — chainable calls that also carry inspectable state

The Singleton Pattern — One Instance, Reused Forever

A singleton is a class that only ever produces one instance. No matter how many times you call Config(), you get the same Config object every time. Perfect for app-wide state — configuration, database connections, logging, caches.

class Config:
    _instance = None                       # class variable — the "one and only" slot

    def __new__(cls, *args, **kwargs):
        if cls._instance is None:
            print("  [__new__] first call — creating THE instance")
            cls._instance = super().__new__(cls)
        else:
            print("  [__new__] already exists — returning the same instance")
        return cls._instance

    def __init__(self, filename=None):
        # NOTE: __init__ runs on EVERY Config(...) call — beware of clobbering
        if filename is not None:
            self.filename = filename


print("First call:")
a = Config("app.ini")

print("\nSecond call:")
b = Config()

print("\nThird call:")
c = Config("override.ini")

print()
print("a is b:", a is b)           # True — literally the same object
print("b is c:", b is c)           # True
print("a.filename:", a.filename)   # override.ini (the last __init__ clobbered it)

Animated Diagram — All Three Calls Return the Same Object

A Safer Singleton — Guard __init__ Too

Because __init__ runs on every construction call, you often want a flag to run the actual setup only once. This is the "initialised once" pattern used in most real singletons.

class ConfigManager:
    _instance = None
    _initialized = False

    def __new__(cls, *args, **kwargs):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
        return cls._instance

    def __init__(self, filename="app.ini"):
        # Guard: don't re-run on subsequent construction calls
        if ConfigManager._initialized:
            return
        print(f"Loading {filename} — this runs ONCE")
        self.filename = filename
        self.settings = {"debug": True, "version": "2.4"}
        ConfigManager._initialized = True


a = ConfigManager("app.ini")             # prints "Loading app.ini..."
b = ConfigManager("different.ini")       # silent — already initialised

print(a.filename)                        # app.ini (still the first value)
print(a is b)                            # True

Alternative Singleton Patterns

The __new__ approach is the most obvious, but Python offers several equivalent patterns. Each fits a different taste in code style.

Pattern 1 — Decorator

def singleton(cls):
    instances = {}
    def get_instance(*args, **kwargs):
        if cls not in instances:
            instances[cls] = cls(*args, **kwargs)
        return instances[cls]
    return get_instance


@singleton
class Database:
    def __init__(self, host):
        self.host = host

db1 = Database("localhost")
db2 = Database("other-host")
print(db1 is db2)   # True
print(db1.host)     # localhost (the second call was ignored)

Pattern 2 — Module-Level (the Pythonic default)

# In config.py — module itself IS the singleton
settings = {"debug": True, "version": "2.4"}

def get(key):
    return settings.get(key)

# Anywhere else:
# from config import settings, get
# Every import gets the same module → same settings dict — natural singleton

Practical Example — A Callable Counter With State

A class that acts like a function but remembers how many times it's been called. Classic __call__ use case.

class Counter:
    def __init__(self, start=0):
        self.count = start

    def __call__(self):
        self.count += 1
        return self.count

    def reset(self):
        self.count = 0

    def __repr__(self):
        return f"Counter(count={self.count})"


c = Counter()
print(c())     # 1  ← invoked like a function
print(c())     # 2
print(c())     # 3

# Still an object — you can inspect and reset
print(c)       # Counter(count=3)
c.reset()
print(c())     # 1 (started over)

# Multiple independent counters — each carries its own state
hits    = Counter()
misses  = Counter()
hits(); hits(); hits()
misses()
print(f"hits={hits.count}, misses={misses.count}")   # hits=3, misses=1

Practical Example — A Callable Validator

Combine __call__ with __init__-time configuration to build small, reusable validation objects. Configure once, call anywhere.

class MinLengthValidator:
    def __init__(self, min_length):
        self.min_length = min_length

    def __call__(self, value):
        # Uses config from __init__ every time it's called
        if len(value) < self.min_length:
            raise ValueError(
                f"{value!r} must be at least {self.min_length} chars"
            )
        return value


# Build once, use everywhere
username_valid = MinLengthValidator(3)
password_valid = MinLengthValidator(8)

# Call the instances like functions
print(username_valid("alice"))       # 'alice'
print(password_valid("SecureP@ss"))  # 'SecureP@ss'

try:
    password_valid("abc")
except ValueError as e:
    print("Blocked:", e)

# Callables can be passed to higher-order functions
inputs = ["alice", "bob", "chandra"]
valid_names = [n for n in inputs if len(n) >= username_valid.min_length]
print(valid_names)

Common Mistakes (and Fixes)

Quick Reference

Golden Rules