DEV Community: MUHAMMAD AHMAD

Understanding `slots` in Python: Memory Optimization and Design Trade-offs

MUHAMMAD AHMAD — Tue, 17 Feb 2026 15:39:23 +0000

Introduction

Python's dynamic nature makes it flexible, but that flexibility comes with memory overhead. Every object stores its attributes in a dictionary (__dict__), which consumes significant memory especially when creating millions of simple data-holding objects. This article examines __slots__, a Python feature that eliminates this overhead, and explores when it improves code quality versus when it introduces unnecessary complexity.

The Problem: Dictionary Overhead

When you define a simple class in Python:

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

p = Point(1, 2)
print(p.__dict__)  # {'x': 1, 'y': 2}

Each Point instance carries a dictionary. On a 64-bit system, an empty dictionary consumes approximately 72 bytes. For a class with two integers, the dictionary overhead exceeds the data itself. When creating large datasets such as geometric coordinates, CSV records, or graph nodes this overhead accumulates rapidly.

The Solution: `slots`

__slots__ declares fixed attributes for a class, replacing the dynamic dictionary with a fixed-size array:

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

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

p = Point(1, 2)
# p.__dict__  # AttributeError: 'Point' object has no attribute '__dict__'

Memory Impact: Quantified

Testing with 1,000,000 instances on CPython 3.11 (64-bit):

Implementation	Bytes per Instance	Total Memory
Standard `__dict__`	~152 bytes	~152 MB
With `__slots__`	~56 bytes	~56 MB
Reduction	63%	96 MB

import sys

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

print(sys.getsizeof(DictPoint(0, 0)))  # ~48 bytes (object header + dict pointer)
print(sys.getsizeof(SlotPoint(0, 0)))  # ~40 bytes (object header only)
# Full overhead includes the separate dictionary object for DictPoint

How `slots` Works

Under CPython's object model, instances store attributes in one of two ways:

Standard Objects:

Instance holds a pointer to __dict__ (a hash table)
Attribute access requires hash computation and table lookup
New attributes can be added dynamically at any time

Slotted Objects:

Attributes stored in a fixed array at known offsets (like C structs)
Access uses array indexing—faster and more cache-friendly
Attribute set is fixed at class definition time

Practical Implementation Patterns

1. Basic Data Classes

class Particle:
    __slots__ = ('position', 'velocity', 'mass')

    def __init__(self, position, velocity, mass):
        self.position = position
        self.velocity = velocity
        self.mass = mass

2. Inheritance Considerations

When using inheritance with __slots__, each class must declare its own slots. Empty __slots__ prevents the creation of __dict__ while inheriting parent's slots:

class Entity:
    __slots__ = ('id', 'created_at')

class User(Entity):
    __slots__ = ('email', 'name')  # Has id, created_at, email, name

class Guest(Entity):
    __slots__ = ()  # Has only id, created_at, no __dict__

3. Preserving Dynamic Attributes

If some instances need dynamic attributes, explicitly include __dict__ in slots:

class Flexible:
    __slots__ = ('required_field', '__dict__')

    def __init__(self):
        self.required_field = "fixed"
        # Can still add: self.dynamic = "value"

4. Enabling Weak References

Objects using __slots__ do not support weak references by default. Add __weakref__ to enable this:

class Node:
    __slots__ = ('value', 'children', '__weakref__')
    # Now weakref.ref(instance) works

When to Use `slots`

Appropriate scenarios:

High-volume data objects (millions of instances)
Simple data containers with fixed schemas
Performance-critical attribute access
Memory-constrained environments (embedded, mobile, containers)

Inappropriate scenarios:

Classes with frequently changing attributes
APIs requiring arbitrary attribute assignment by users
Classes needing simple pickling without custom methods
Code where readability matters more than marginal memory gains

Performance Beyond Memory

__slots__ improves runtime performance through faster attribute access:

import timeit

class DictObj:
    def __init__(self):
        self.x = 0

class SlotObj:
    __slots__ = ('x',)
    def __init__(self):
        self.x = 0

# Attribute access timing
dict_time = timeit.timeit('obj.x', setup='from __main__ import DictObj; obj = DictObj()')
slot_time = timeit.timeit('obj.x', setup='from __main__ import SlotObj; obj = SlotObj()')

print(f"Dict access: {dict_time:.4f}")
print(f"Slot access: {slot_time:.4f}")
# Slot access typically 10-20% faster due to array indexing vs hash lookup

Common Pitfalls

Pitfall 1: Multiple inheritance conflicts

class A:
    __slots__ = ('a',)

class B:
    __slots__ = ('b',)

class C(A, B):
    __slots__ = ('c',)  # Valid

class D(A, B):
    pass  # Also valid—creates __dict__ if not using slots

Pitfall 2: Forgetting __weakref__

class Cached:
    __slots__ = ('data',)

import weakref
c = Cached()
# weakref.ref(c)  # TypeError: cannot create weak reference

Pitfall 3: Pickling complications

Standard pickling works with __slots__, but custom __getstate__ and __setstate__ may be needed for complex scenarios:

class Persistent:
    __slots__ = ('value', 'temp_cache')

    def __getstate__(self):
        return {'value': self.value}  # Exclude temp_cache

    def __setstate__(self, state):
        self.value = state['value']

Design Best Practices

1. Start Simple, Optimize When Measured

Do not default to __slots__. Write standard classes first. Use memory profiling (tracemalloc, pympler) to identify actual bottlenecks before adding complexity.

2. Document Intent Clearly

class Coordinate:
    """
    Memory-optimized coordinate for large-scale geometry processing.

    Uses __slots__ to reduce footprint from ~152 bytes to ~56 bytes
    per instance, critical when handling millions of points.
    """
    __slots__ = ('x', 'y', 'z')

3. Abstract Implementation Details

If switching between slotted and dict-based implementations, use a factory or abstract the decision:

from dataclasses import dataclass
from typing import NamedTuple

# Option 1: dataclass with slots (Python 3.10+)
@dataclass(slots=True)
class Point:
    x: float
    y: float

# Option 2: NamedTuple (immutable, automatically slotted)
class Point(NamedTuple):
    x: float
    y: float

4. Test Both Implementations

When performance matters, maintain test suites verifying both implementations produce identical behavior:

def test_coordinate_behavior(PointClass):
    p = PointClass(1.0, 2.0)
    assert p.x == 1.0
    assert p.y == 2.0
    # Test all expected behavior...

# Run against both implementations
test_coordinate_behavior(DictPoint)
test_coordinate_behavior(SlotPoint)

Alternatives to Consider

Before adopting __slots__, evaluate these alternatives:

Approach	Memory Efficiency	Mutability	Use Case
`__slots__`	High	Yes	Many mutable objects
`NamedTuple`	High	No	Immutable records
`@dataclass(slots=True)`	High	Yes	Clean syntax, Python 3.10+
`array.array`	Very High	Yes	Homogeneous numeric data
`numpy.ndarray`	Very High	Yes	Numerical computing
`pandas.DataFrame`	Very High	Yes	Tabular data

Conclusion

__slots__ is a specialized tool, not a universal improvement. It trades Python's dynamic flexibility for memory efficiency and attribute access speed. Use it when profiling identifies memory pressure from object overhead, particularly in data-intensive applications. Avoid it when code clarity, flexibility, or rapid prototyping takes priority.

The most robust approach: write clear, correct code first, measure resource usage, then apply targeted optimizations where data proves they matter.

𝗧𝘄𝗼 𝘄𝗼𝗿𝗱𝘀 𝘁𝗼 𝗿𝗲𝗱𝘂𝗰𝗲 𝗔𝗜 𝗵𝗮𝗹𝗹𝘂𝗰𝗶𝗻𝗮𝘁𝗶𝗼𝗻 𝘀𝗶𝗴𝗻𝗶𝗳𝗶𝗰𝗮𝗻𝘁𝗹𝘆

MUHAMMAD AHMAD — Tue, 17 Feb 2026 15:31:40 +0000

Most of us know the frustration hallucination doesn't just give us wrong answers; it traps us in cycles of mistakes, compounding errors until we're miles from the truth.

Here's what changed my results: Instead of just asking AI to "think step by step" (chain of thought), I now end every prompt with: "𝘋𝘰 𝘢 𝘥𝘦𝘦𝘱 𝙨𝙩𝙧𝙚𝙨𝙨 𝙩𝙚𝙨𝙩 𝘢𝘨𝘢𝘪𝘯𝘴𝘵 𝘺𝘰𝘶𝘳 𝘢𝘯𝘴𝘸𝘦𝘳."

The difference? Chain of thought lets the model reason sequentially but it never questions itself. A stress test forces it to interrogate its own logic, spot weaknesses, and surface uncertainties before you ever see the output.

𝘐'𝘮 𝘢𝘤𝘵𝘪𝘷𝘦𝘭𝘺 𝘳𝘦𝘴𝘦𝘢𝘳𝘤𝘩𝘪𝘯𝘨 𝘵𝘩𝘪𝘴 𝘢𝘯𝘥 𝘳𝘦𝘭𝘢𝘵𝘦𝘥 𝘵𝘦𝘤𝘩𝘯𝘪𝘲𝘶𝘦𝘴, 𝘧𝘪𝘯𝘢𝘭𝘪𝘻𝘪𝘯𝘨 𝘴𝘰𝘮𝘦 𝘧𝘳𝘢𝘮𝘦𝘸𝘰𝘳𝘬𝘴 𝘵𝘩𝘢𝘵 𝘐 𝘣𝘦𝘭𝘪𝘦𝘷𝘦 𝘤𝘢𝘯 𝘮𝘦𝘢𝘯𝘪𝘯𝘨𝘧𝘶𝘭𝘭𝘺 𝘪𝘮𝘱𝘳𝘰𝘷𝘦 𝘩𝘰𝘸 𝘸𝘦 𝘸𝘰𝘳𝘬 𝘸𝘪𝘵𝘩 𝘈𝘐. 𝘐𝘧 𝘺𝘰𝘶'𝘳𝘦 𝘦𝘹𝘱𝘦𝘳𝘪𝘮𝘦𝘯𝘵𝘪𝘯𝘨 𝘸𝘪𝘵𝘩 𝘱𝘳𝘰𝘮𝘱𝘵 𝘦𝘯𝘨𝘪𝘯𝘦𝘦𝘳𝘪𝘯𝘨, 𝘈𝘐 𝘳𝘦𝘭𝘪𝘢𝘣𝘪𝘭𝘪𝘵𝘺, 𝘰𝘳 𝘫𝘶𝘴𝘵 𝘵𝘪𝘳𝘦𝘥 𝘰𝘧 𝘤𝘩𝘢𝘴𝘪𝘯𝘨 𝘩𝘢𝘭𝘭𝘶𝘤𝘪𝘯𝘢𝘵𝘪𝘰𝘯𝘴 𝘐'𝘥 𝘭𝘰𝘷𝘦 𝘵𝘰 𝘤𝘰𝘯𝘯𝘦𝘤𝘵 𝘢𝘯𝘥 𝘦𝘹𝘤𝘩𝘢𝘯𝘨𝘦 𝘪𝘥𝘦𝘢𝘴.

𝗜 𝗳𝗼𝘂𝗻𝗱 𝗮 𝗱𝗲𝗮𝗱-𝘀𝗶𝗺𝗽𝗹𝗲 𝘄𝗮𝘆 𝘁𝗼 𝗰𝘂𝘁 𝗨𝗜 𝗰𝗹𝘂𝘁𝘁𝗲𝗿 𝘄𝗵𝗲𝗻 𝘃𝗶𝗯𝗲-𝗰𝗼𝗱𝗶𝗻𝗴 𝘄𝗶𝘁𝗵 𝗔𝗜 𝗮𝗴𝗲𝗻𝘁𝘀.

MUHAMMAD AHMAD — Mon, 16 Feb 2026 07:06:14 +0000

While building a visual forensic UX research tool using Google AI Studio, I found a trick to fix UI/UX issues when vibe-coding: instead of treating the AI as one assistant who "fixes" your interface, I started running it as multiple simulated users each with their own goals, frustrations, and blind spots.

𝗧𝗵𝗲 𝗽𝗿𝗼𝗺𝗽𝘁:
"𝘈𝘤𝘵 𝘭𝘪𝘬𝘦 𝘢 𝘜𝘟 𝘳𝘦𝘴𝘦𝘢𝘳𝘤𝘩𝘦𝘳. 𝘚𝘪𝘮𝘶𝘭𝘢𝘵𝘦 𝘩𝘰𝘸 𝘥𝘪𝘧𝘧𝘦𝘳𝘦𝘯𝘵 𝘶𝘴𝘦𝘳𝘴 𝘸𝘰𝘶𝘭𝘥 𝘦𝘹𝘱𝘦𝘳𝘪𝘦𝘯𝘤𝘦 𝘵𝘩𝘪𝘴 𝘪𝘯𝘵𝘦𝘳𝘧𝘢𝘤𝘦: 𝘢 𝘳𝘶𝘴𝘩𝘦𝘥 𝘤𝘰𝘮𝘮𝘶𝘵𝘦𝘳 𝘤𝘩𝘦𝘤𝘬𝘪𝘯𝘨 𝘪𝘵 𝘰𝘯 𝘮𝘰𝘣𝘪𝘭𝘦, 𝘢 𝘴𝘬𝘦𝘱𝘵𝘪𝘤𝘢𝘭 𝘦𝘯𝘵𝘦𝘳𝘱𝘳𝘪𝘴𝘦 𝘣𝘶𝘺𝘦𝘳 𝘦𝘷𝘢𝘭𝘶𝘢𝘵𝘪𝘯𝘨 𝘴𝘦𝘤𝘶𝘳𝘪𝘵𝘺, 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘸𝘩𝘰 𝘴𝘬𝘪𝘱𝘱𝘦𝘥 𝘵𝘩𝘦 𝘰𝘯𝘣𝘰𝘢𝘳𝘥𝘪𝘯𝘨. 𝘞𝘩𝘦𝘳𝘦 𝘥𝘰 𝘵𝘩𝘦𝘺 𝘨𝘦𝘵 𝘴𝘵𝘶𝘤𝘬? 𝘞𝘩𝘢𝘵 𝘥𝘰 𝘵𝘩𝘦𝘺 𝘮𝘪𝘴𝘶𝘯𝘥𝘦𝘳𝘴𝘵𝘢𝘯𝘥? 𝘍𝘰𝘳𝘮𝘢𝘭𝘪𝘻𝘦 𝘢 𝘤𝘰𝘯𝘤𝘪𝘴𝘦 𝘳𝘦𝘱𝘰𝘳𝘵 𝘪𝘯 𝘶𝘹_𝘳𝘦𝘴𝘦𝘢𝘳𝘤𝘩.𝘮𝘥 𝘧𝘪𝘭𝘦 𝘢𝘯𝘥 𝘴𝘶𝘨𝘨𝘦𝘴𝘵 𝘤𝘩𝘢𝘯𝘨𝘪𝘯𝘨𝘴."

𝗪𝗵𝘆 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀: The AI generates structured, persona-based feedback instead of generic suggestions. You get specific friction points, not fluff.

𝗧𝗵𝗲 𝗿𝗲𝘀𝘂𝗹𝘁: Faster iteration, less bloat, and UI decisions backed by simulated multi-perspective research without the research timeline.

No frameworks. No buzzwords. Just a prompt that forces the AI to argue with itself before it gives you advice. And finally, you can implement without getting headache when you ask AI for changings and it removes functionalities in app.

Building with Cursor, Antigravity, or AI Studio? Try it on your next screen.

Two markdown hacks that changed how I vibe code

MUHAMMAD AHMAD — Sun, 15 Feb 2026 04:06:33 +0000

𝟭. 𝗧𝗵𝗲 𝗣𝗿𝗼𝗰𝗲𝘀𝘀 𝗖𝗮𝗽𝘁𝘂𝗿𝗲 𝗛𝗮𝗰𝗸

Before you start any session, create a 𝘗𝘙𝘖𝘊𝘌𝘚𝘚.𝘮𝘥 file. Tell your agent (e.g #GoogleAntigravity #GitHubCopilot): "𝘋𝘰𝘤𝘶𝘮𝘦𝘯𝘵 𝘦𝘷𝘦𝘳𝘺 𝘥𝘦𝘤𝘪𝘴𝘪𝘰𝘯, 𝘦𝘷𝘦𝘳𝘺 𝘪𝘵𝘦𝘳𝘢𝘵𝘪𝘰𝘯, 𝘦𝘷𝘦𝘳𝘺 𝘥𝘦𝘢𝘥 𝘦𝘯𝘥 𝘪𝘯 𝘵𝘩𝘪𝘴 𝘧𝘪𝘭𝘦."

Why it works: You're not just building a product. You're building a reusable instruction manual. Next time you hand that file to a new agent, it doesn't start from zero. It starts from your accumulated context.

𝟮. 𝗧𝗵𝗲 𝗗𝗲𝘀𝗶𝗴𝗻 𝗧𝗿𝗮𝗻𝘀𝗹𝗮𝘁𝗶𝗼𝗻 𝗛𝗮𝗰𝗸

Found a website you want to emulate? Don't describe it. Screenshot it. Feed those images to an AI (e.g #Google Gemini Nanobanana) with this prompt: "𝘞𝘳𝘪𝘵𝘦 𝘢 𝘥𝘦𝘴𝘪𝘨𝘯.𝘮𝘥 𝘵𝘩𝘢𝘵 𝘣𝘳𝘦𝘢𝘬𝘴 𝘥𝘰𝘸𝘯 𝘵𝘩𝘦 𝘭𝘢𝘺𝘰𝘶𝘵, 𝘴𝘱𝘢𝘤𝘪𝘯𝘨, 𝘵𝘺𝘱𝘰𝘨𝘳𝘢𝘱𝘩𝘺, 𝘤𝘰𝘭𝘰𝘳 𝘭𝘰𝘨𝘪𝘤, 𝘢𝘯𝘥 𝘪𝘯𝘵𝘦𝘳𝘢𝘤𝘵𝘪𝘰𝘯 𝘱𝘢𝘵𝘵𝘦𝘳𝘯𝘴."
Then hand that 𝘥𝘦𝘴𝘪𝘨𝘯.𝘮𝘥 to your coding agent. No more "make it look modern" ambiguity. You have a structured spec derived from visual reality.

𝗧𝗵𝗲 𝗽𝗮𝘁𝘁𝗲𝗿𝗻: Markdown isn't just for READMEs. It's the bridge between human taste and agent execution.

What patterns are you using?