Python __slots__ — Why Your Subclass Still Has __dict__

Most Python objects carry a __dict__ — a hash map storing all instance attributes. For a small number of large objects this is fine. For millions of small objects (coordinate points, events, records), the dict overhead becomes significant.

__slots__ is the mechanism for trading flexibility for efficiency. Once you define __slots__, your class no longer has a __dict__ per instance, and attributes are stored as fixed C-level offsets instead.

What __slots__ Actually Does — and Doesn't

__slots__ is a class-level attribute that tells Python to reserve a fixed-size array for instance attributes instead of the per-instance __dict__. This eliminates the hash table overhead — each slot becomes a descriptor that stores the value at a known offset in the instance's internal struct. The result: each instance saves ~64 bytes (the __dict__ overhead) and attribute access becomes a direct array lookup instead of a hash-table probe, giving a measurable speedup in tight loops.

Crucially, __slots__ only applies to the class that defines it. Subclasses that don't redeclare __slots__ will still get a __dict__ — and if they do declare __slots__, they inherit the parent's slots but also get their own __dict__ unless they explicitly set __slots__ = () to suppress it. This is the single most common source of confusion: developers assume __slots__ is inherited like a method, but it's not — it's a per-class declaration that controls the layout of that class's instances.

Use __slots__ when you have many instances (thousands or more) of a simple data-holder class — for example, ORM models, game entities, or configuration objects. The memory savings are linear: 100,000 instances save ~6 MB of dict overhead. But never use __slots__ on classes that need dynamic attribute assignment, weak references (unless you add __weakref__ to slots), or inheritance chains where subclasses add attributes — the complexity quickly outweighs the benefit.

Basic __slots__ Usage

To use __slots__, declare a class-level attribute __slots__ containing a tuple or list of attribute names. That's it. CPython then allocates fixed-size descriptors for these names instead of a per-instance __dict__.

You can still assign values normally in __init__. The difference is you can't add new attributes after __init__. Trying to do so raises AttributeError.

This is the simplest way to get the memory win — but watch out for inheritance gotchas (see later section).

import sys

# Without __slots__ — each instance has a __dict__
class PointDict:
    def __init__(self, x, y):
        self.x = x
        self.y = y

# With __slots__ — no __dict__, fixed attributes only
class PointSlots:
    __slots__ = ('x', 'y')

    def __init__(self, x, y):
        self.x = x
        self.y = y

p_dict  = PointDict(1.0, 2.0)
p_slots = PointSlots(1.0, 2.0)

print(sys.getsizeof(p_dict))   # ~48 bytes (object) + ~232 bytes (dict) = ~280
print(sys.getsizeof(p_slots))  # ~56 bytes — no dict

# __dict__ exists on PointDict but not PointSlots
print(hasattr(p_dict,  '__dict__'))  # True
print(hasattr(p_slots, '__dict__'))  # False

# Dynamic attribute assignment blocked
try:
    p_slots.z = 3.0  # AttributeError
except AttributeError as e:
    print(e)  # 'PointSlots' object has no attribute 'z'

Memory Savings at Scale

The memory win is real when you handle tens of thousands of objects. Each Python object without __slots__ carries a __dict__ overhead of about 232 bytes (for a typical dict) plus the object header. With __slots__, you only have the object header and the slot values — typically 40-80 bytes total.

Here's a benchmark comparing 100,000 event objects with and without __slots__:

import tracemalloc

class EventDict:
    def __init__(self, ts, kind, value):
        self.ts = ts; self.kind = kind; self.value = value

class EventSlots:
    __slots__ = ('ts', 'kind', 'value')
    def __init__(self, ts, kind, value):
        self.ts = ts; self.kind = kind; self.value = value

N = 100_000

tracemalloc.start()
events_dict = [EventDict(i, 'click', i * 1.5) for i in range(N)]
_, peak_dict = tracemalloc.get_traced_memory()
tracemalloc.stop()

tracemalloc.start()
events_slots = [EventSlots(i, 'click', i * 1.5) for i in range(N)]
_, peak_slots = tracemalloc.get_traced_memory()
tracemalloc.stop()

print(f"Dict:  {peak_dict / 1024 / 1024:.1f} MB")
print(f"Slots: {peak_slots / 1024 / 1024:.1f} MB")
print(f"Saving: {(1 - peak_slots/peak_dict)*100:.0f}%")

Inheritance and __slots__

Here's the trap most engineers hit: __slots__ in a parent class does NOT carry over to child classes. Each subclass must define its own __slots__, otherwise the subclass instances will still have a __dict__ — and you lose the memory benefit.

If a subclass defines __slots__, it can only include the new attributes it adds, not the parent's. Python merges them at the C level automatically.

What happens if a parent class does NOT use __slots__? Then any subclass that uses __slots__ will STILL have a __dict__ because the parent provides one. The only way to avoid that is to include '__dict__' in the parent's __slots__ (defeating the purpose) or to refactor the hierarchy.

class Base:
    __slots__ = ('x', 'y')

class ChildWithSlots(Base):
    __slots__ = ('z',)  # <- only new slots, parent's x,y merged automatically

class ChildWithoutSlots(Base):
    pass  # <- BEWARE: this child still has __dict__!

c1 = ChildWithSlots()
print(hasattr(c1, '__dict__'))  # False

c2 = ChildWithoutSlots()
print(hasattr(c2, '__dict__'))  # True!  Memory benefit lost.

# What if parent has no __slots__?
class NoSlotsBase:
    pass

class ChildSlotsOnNoSlots(NoSlotsBase):
    __slots__ = ('a',)

c3 = ChildSlotsOnNoSlots()
print(hasattr(c3, '__dict__'))  # True — inherited from NoSlotsBase
print(hasattr(c3, '__slots__')) # True — but __dict__ still exists

Performance: Attribute Access Speed

Removing the dict hash lookup gives you a small but measurable speed boost for reading and writing attributes. In microbenchmarks, __slots__ attribute access is about 10-20% faster than dict-backed access. For most applications the difference is negligible, but in tight loops (e.g., game physics, data processing pipelines) it can add up.

Note that the speed gain comes from avoiding the hash computation and dict resize overhead, not from eliminating the attribute itself. Writing to a slot is still a Python attribute set operation, but it bypasses the dict insertion path.

import timeit

class DictPoint:
    def __init__(self, x, y):
        self.x = x
        self.y = y

class SlotPoint:
    __slots__ = ('x', 'y')
    def __init__(self, x, y):
        self.x = x
        self.y = y

dp = DictPoint(1.0, 2.0)
sp = SlotPoint(1.0, 2.0)

def read_dict():
    _ = dp.x + dp.y

def read_slot():
    _ = sp.x + sp.y

# Time in microseconds per loop
t_dict = timeit.timeit(read_dict, number=10_000_000)
t_slot = timeit.timeit(read_slot, number=10_000_000)
print(f"Dict read:  {t_dict:.2f}s")
print(f"Slot read:  {t_slot:.2f}s")
print(f"Speedup:    {(1 - t_slot/t_dict)*100:.1f}%")

# Write speed
def write_dict():
    dp.x = 3.0; dp.y = 4.0

def write_slot():
    sp.x = 3.0; sp.y = 4.0

t_wdict = timeit.timeit(write_dict, number=10_000_000)
t_wslot = timeit.timeit(write_slot, number=10_000_000)
print(f"Dict write: {t_wdict:.2f}s")
print(f"Slot write: {t_wslot:.2f}s")
print(f"Speedup:    {(1 - t_wslot/t_wdict)*100:.1f}%")

Use Cases and Trade-offs

__slots__ shines where you have many small, simple objects. Classic use cases: - Data transfer objects (DTOs) representing rows, API responses, or log entries - Game entities (player positions, bullets, particles) - Large collections of immutable value objects (coordinates, timestamps) - Objects that are serialized/deserialized frequently (less memory pressure reduces GC pauses)

Trade-offs you must accept: 1. No dynamic attributes — every attribute must be declared at class definition. 2. Breaks some libraries: Django models, SQLAlchemy's ORM, and many patches that rely on __dict__. You can't use __slots__ with those out of the box. 3. Inheritance complexity as discussed. 4. Weak references: classes with __slots__ can't be weakly referenced unless you add '__weakref__' to __slots__. 5. Default values: You can't set default values in __slots__ directly; you need to handle them in __init__.

import weakref

class WithSlots:
    __slots__ = ('data',)
    def __init__(self, data):
        self.data = data

obj = WithSlots(42)
try:
    r = weakref.ref(obj)  # Raises TypeError: cannot create weak reference to 'WithSlots' object
except TypeError as e:
    print(e)

# Fix: add '__weakref__' to __slots__
class WithSlotsWeak:
    __slots__ = ('data', '__weakref__')
    def __init__(self, data):
        self.data = data

obj2 = WithSlotsWeak(42)
r2 = weakref.ref(obj2)  # Works
print(r2().data)

Alternatives and Best Practices

Best practices: 1. Measure before and after: never rely on intuition. Use sys.getsizeof() and tracemalloc. 2. Keep __slots__ at the leaf classes of your hierarchy; avoid putting it on abstract base classes. 3. Document the trade-off explicitly in the class docstring. 4. If you inherit from a C extension type (e.g., tuple, list), __slots__ may not work; check the type's tp_dictoffset.

from dataclasses import dataclass

# Python 3.10+ — slots=True generates __slots__ automatically
@dataclass(slots=True)
class Point:
    x: float
    y: float

p = Point(1.0, 2.0)
print(hasattr(p, '__dict__'))  # False
print(hasattr(p, '__slots__')) # True
print(p.x)  # 1.0

# But you still can't add attributes dynamically
try:
    p.z = 3.0
except AttributeError as e:
    print(e)

# For pre-3.10, you can't use slots=True; fallback to manual __slots__

Why __slots__ Breaks Pickling (and What to Do)

You just decorated a high-volume data class with __slots__ to cut memory. Great. Now your serialization pipeline throws AttributeError: 'MyRecord' object has no attribute '__dict__'. This is the first thing that burns juniors in production.

Pickle and copy.deepcopy rely on __dict__ by default. When you kill the dict, you kill naive serialization. The fix isn't to remove slots — it's to implement __getstate__ and __setstate__. Or switch to __reduce__ if you need pickle protocol 2+.

For JSON serialization, you already have a method. Add __json__ or use dataclasses with slots=True which handles this for you. Never assume your downstream consumers can handle slot-based objects without explicit support.

If you use multiprocessing, check your pickling path before rollout. I've seen a 200-node cluster silently fail because a slot-based config object couldn't be serialized across workers. Test this during system testing, not after deployment.

// io.thecodeforge
import pickle

class Record:
    __slots__ = ('id', 'value')

    def __init__(self, id, value):
        self.id = id
        self.value = value

    # Required for pickle to work without __dict__
    def __getstate__(self):
        return {slot: getattr(self, slot) for slot in self.__slots__}

    def __setstate__(self, state):
        for slot, val in state.items():
            setattr(self, slot, val)

r = Record(42, "production")
data = pickle.dumps(r)
restored = pickle.loads(data)
print(restored.id, restored.value)  # 42 production

How __slots__ Breaks Weak References (Fixed With __weakref__)

Your caching layer uses weakref.WeakValueDictionary to hold slot objects. Good idea — until objects get garbage collected immediately because you forgot one line. When you define __slots__, you also remove the __weakref__ attribute that Python's garbage collector uses for weak references.

The symptom: Every object you add to the weak dictionary disappears instantly. Your cache evicts entries on insertion. This is another silent failure that only shows up under load.

Fix: Add '__weakref__' to your __slots__ tuple. It's a reserved slot name that restores weak reference support without bringing back the full __dict__. Do this whenever your objects participate in any caching, observer pattern, or event system.

If you're using weakref.finalize for cleanup, same problem applies. Python 3.4+ has __weakref__ as a standard slot, but you must declare it explicitly when overriding __slots__. Otherwise your destructors never run.

Rule of thumb: If your class is used in a cache, callbacks, or async context, add '__weakref__' to slots. It costs ~8 bytes per object and saves hours of hair-pulling.

// io.thecodeforge
import weakref

class CacheNode:
    # Without __weakref__, this object can't be weakly referenced
    __slots__ = ('key', 'data', '__weakref__')

    def __init__(self, key, data):
        self.key = key
        self.data = data

cache = weakref.WeakValueDictionary()
node = CacheNode(1, "payload")
cache[node.key] = node

print(len(cache))  # 1, not 0
# Without __weakref__, this would print 0 — the object dies immediately