Forem: Heval Hazal Kurt

Why Composition Beats Inheritance in Large-Scale Python Systems

Heval Hazal Kurt — Wed, 03 Dec 2025 18:02:02 +0000

When you start out learning object-oriented programming (OOP) in Python, inheritance feels like the obvious way to reuse code. You build a base class, extend it, and reuse its behavior. But as your software grows, you might start noticing that inheritance introduces tight coupling, rigid structures, and eventually... a mess.

This post is about why composition is often a better choice than inheritance in large-scale Python systems, especially when you're building backend applications. We’ll start from the basics, then go into real-life backend scenarios to show how composition can help you write cleaner, more maintainable code.

Inheritance vs Composition

Inheritance means creating a new class that is a type of another class. It forms an "is-a" relationship. The child class (subclass) automatically gets the properties and methods of the parent (base) class. This is great when the subclass truly is a specialized form of the parent.

class Animal:
    def speak(self):
        return "Some sound"

class Dog(Animal):
    def speak(self):
        return "Woof!"

Here, Dog is an Animal, so it makes sense to inherit. But if you start inheriting just to reuse speak(), that's a red flag, you're misusing inheritance.

Composition, on the other hand, means building a class using other classes often by passing them in as attributes. It forms a “has-a” relationship. One class delegates behavior to another, which makes the structure more flexible and modular.

class Engine:
    def start(self):
        return "Engine started"

class Car:
    def __init__(self, engine):
        self.engine = engine

    def start(self):
        return self.engine.start()

Here, Car has an Engine, and it uses the engine's behavior without being tightly bound to its implementation. This makes testing, swapping, or extending Engine behavior much easier.

To sum it up:

Use inheritance when you have a clear hierarchical relationship.
Use composition when you want flexibility, testability, and better separation of concerns.

The Problems with Inheritance in Big Codebases

In small systems, inheritance can work fine. But once you scale up, it starts to cause trouble:

1. Tight Coupling

Child classes depend on the structure of the parent. If you change the base class, you risk breaking subclasses.

2. Inheritance Hierarchies Get Deep and Confusing

When you have a base class, a child class, a grandchild class... it's hard to track where methods are coming from.

3. Inheritance Isn’t Flexible

What if you need to reuse the same behavior in two unrelated classes? Inheritance can’t help without breaking the “is-a” rule.

4. Testing Becomes Harder

When behavior is inherited from many levels up, writing isolated unit tests becomes a pain.

Composition to the Rescue

With composition, you build classes that contain instances of other classes. This way, your classes are like Lego blocks: reusable, testable, and loosely coupled. Let’s walk through some backend scenarios where composition shines.

Scenario 1: Injecting Services into API Endpoints

When building real-world APIs, for example with FastAPI or Flask, you often need to integrate services like email delivery, logging, analytics, or third-party APIs. A common mistake is to tightly bind these services into the route or controller logic, or worse, to subclass everything in an attempt to "reuse" behavior. That’s where composition becomes a huge win.

Let's say your API should send a welcome email when a new user signs up. You might be tempted to create a BaseSignupHandler with a send_email method, and then subclass it. But that approach hardwires the behavior and makes testing or swapping the email logic a pain.

Instead, you can define a dedicated service class:

class EmailService:
    def send(self, to, subject, body):
        # Send email logic here
        print(f"Sending to {to}: {subject}")

class UserSignupHandler:
    def __init__(self, email_service: EmailService):
        self.email_service = email_service

    def signup(self, user_email):
        # Create user...
        self.email_service.send(
            to=user_email,
            subject="Welcome!",
            body="Thanks for signing up."
        )

This gives you several advantages:

Testability: You can mock or stub the email service without changing UserSignupHandler:

class MockEmailService:
    def send(self, to, subject, body):
        print("Mock send")

Now your tests can look like:

handler = UserSignupHandler(MockEmailService())
handler.signup("test@example.com")

Flexibility: Tomorrow you may want to send Slack notifications or SMS instead of email. With composition, you can simply replace EmailService with another implementation. No inheritance gymnastics required.

Decoupling: UserSignupHandler doesn't care how the message is sent. It only knows it can delegate to the service object. This keeps business logic clean and isolated.

In backend systems, you'll commonly inject:

Database repositories
Messaging clients like Kafka, RabbitMQ
External API clients like Stripe, AWS SDKs
Logger or metrics providers

Each of these is a perfect candidate for composition.

By embracing composition for service injection, you’re not only making your code easier to maintain and test. You're also aligning with modern software engineering practices like dependency injection and separation of concerns.

Say you’re writing a FastAPI app that has to send emails. Instead of subclassing some EmailSenderBase, you use composition:

Scenario 2: Payments with Strategy Pattern via Composition

Let’s say your app supports multiple payment gateways:

class StripePayment:
    def charge(self, amount):
        print(f"Charging ${amount} using Stripe")

class PaypalPayment:
    def charge(self, amount):
        print(f"Charging ${amount} using PayPal")

class PaymentProcessor:
    def __init__(self, strategy):
        self.strategy = strategy

    def pay(self, amount):
        return self.strategy.charge(amount)

You can switch strategies at runtime:

processor = PaymentProcessor(StripePayment())
processor.pay(100)  # Uses Stripe

processor.strategy = PaypalPayment()
processor.pay(200)  # Now uses PayPal

This level of flexibility is very hard to achieve with inheritance.

Scenario 3: Repository Pattern with Swappable Storage

Let’s say you want to store user data, but don’t want your business logic to care whether it’s PostgreSQL or Redis.

class PostgresUserRepo:
    def get_user(self, user_id):
        return {"id": user_id, "name": "Postgres User"}

class RedisUserRepo:
    def get_user(self, user_id):
        return {"id": user_id, "name": "Redis Cached User"}

class UserService:
    def __init__(self, user_repo):
        self.user_repo = user_repo

    def load_user(self, user_id):
        return self.user_repo.get_user(user_id)

In tests, you might use an in-memory version:

class InMemoryUserRepo:
    def get_user(self, user_id):
        return {"id": user_id, "name": "Test User"}

Advantages of Composition in Production Code

Loose Coupling

You can change internal parts without touching other parts of the system.
Easier Testing

Just inject mock or fake objects.
More Reuse

Composable behaviors can be shared across unrelated classes.
Better Code Organization

Each class has one responsibility. You don’t need to dig through long inheritance trees.
Dynamic Behavior

You can change or decorate behavior at runtime.

So..

In short, inheritance is great when there is a true "is-a" relationship. But in real-world backend code, that’s rare. What you really need is flexible, maintainable, and testable code. That’s where composition shines.

The original post is here.

The Art of Scope Management in Modular Python Design

Heval Hazal Kurt — Tue, 28 Oct 2025 17:18:55 +0000

When you work on a large Python codebase, especially in backend projects using Django, FastAPI, or Flask, you probably see the chaos that poor scope management can cause. From mysterious bugs and unpredictable state to namespace collisions and tangled dependencies, things get messy fast when variable scope isn’t handled with care.

What Is “Scope” in Python?

In simple terms, scope is where a variable can be seen or used. For example:

def greet():
    name = "Alice"
    print(name)

print(name)  # NameError: name is not defined

Here, name is only visible inside the greet() function. That’s its scope. Python uses something called the LEGB rule to decide how it looks for variables.

The LEGB Rule: Python’s Scope Lookup Chain

This rule stands for:

Local – variables defined inside a function.
Enclosing – variables in parent functions when functions are nested.
Global – variables defined at the module level.
Built-in – stuff that comes with Python, like len, print, range.

When you reference a variable, Python starts at the innermost scope and moves outward until it finds it. Here’s a quick example:

x = "global"

def outer():
    x = "enclosing"

    def inner():
        x = "local"
        print(x)

    inner()

outer()  # prints "local"

If you remove x = "local" from inner(), Python prints "enclosing" — and if that’s gone too, it prints "global". This rule is simple… until your app grows.

Why Scope Matters

Let’s say you're building a backend service with FastAPI, and you start breaking your code into modules:

/project
  ├── main.py
  ├── database.py
  ├── models.py
  ├── routers/
  │     └── user.py

If you don’t manage scope carefully, you’ll run into things like:

Circular imports
Unpredictable globals
Variables that vanish or leak
Hard-to-debug state in production

Let’s see how you can manage scope cleanly.

Rule 1: Keep Your Global Scope Clean

Your main.py is your entry point. It should only:

Start the app
Include global configuration (maybe via os.environ)
Register routers and services

Good:

# main.py
from fastapi import FastAPI
from routers import user

app = FastAPI()

app.include_router(user.router)

Bad:

# main.py
db_connection = connect_to_db()
SOME_MAGIC_GLOBAL_STATE = {}

# Used all over your app without structure

Why it’s bad: When you use global mutable objects, things can go wrong in concurrency, testing, or scaling. They also make your app harder to test.

Instead: Pass state as arguments or use dependency injection, FastAPI supports this.

Use Module Scope for Reusability

Imagine you have a database.py file that sets up your DB engine:

# database.py
from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker

engine = create_engine("sqlite:///example.db")
SessionLocal = sessionmaker(bind=engine)

This is good use of module scope. When you import SessionLocal, it’s consistent and controlled.

Example:

# routers/user.py
from fastapi import Depends
from sqlalchemy.orm import Session
from database import SessionLocal

def get_db():
    db = SessionLocal()
    try:
        yield db
    finally:
        db.close()

@router.get("/users/")
def read_users(db: Session = Depends(get_db)):
    return db.query(User).all()

Notice how we don’t expose too much. We don’t let engine float around everywhere. SessionLocal is the scoped, reusable object.

Avoid Import-Time Side Effects

A common mistake:

# models.py
from database import SessionLocal

SessionLocal().execute("DROP TABLE users;")  # this runs on import

Importing a module should not perform dangerous actions. That’s a scope + timing issue.

Instead:

Keep logic inside functions.
Only run them when explicitly called.
Avoid code at the top level that mutates or acts.

Advanced Scope Patterns for Large Projects

Let’s get into deeper waters.

1. Dependency Injection with Scope Control

FastAPI lets you use function-level scope to inject services:

def get_current_user(token: str = Depends(oauth2_scheme)):
    user = decode_token(token)
    return user

This is better than making current_user a global variable. It’s safer, more testable, and better scoped.

Using Classes to Encapsulate State

Sometimes, you need state. Don’t abuse globals, use classes:

# services/user_service.py
class UserService:
    def __init__(self, db):
        self.db = db

    def get_user(self, user_id):
        return self.db.query(User).filter_by(id=user_id).first()

In your endpoint:

@router.get("/users/{user_id}")
def get_user(user_id: int, db: Session = Depends(get_db)):
    service = UserService(db)
    return service.get_user(user_id)

Here, db is passed down cleanly, no surprises, no globals.

Factory Functions and Closures for Configurable Behavior

Sometimes closures help with scope:

def make_greeting(prefix):
    def greet(name):
        return f"{prefix}, {name}!"
    return greet

hello = make_greeting("Hello")
print(hello("Alice"))  # Hello, Alice!

Use this in backends to build things like custom validators, filters, or pipelines with stored context.

Clean Scope = Clean Code

To wrap it up, good scope management makes your Python code:

Easier to test
Easier to maintain
Safer in production
Faster to understand

Here’s a quick cheat sheet:

Do This	Avoid This
Use local variables inside funcs	Using global variables as shared state
Pass arguments explicitly	Relying on outer scope invisibly
Encapsulate state with classes	Spreading config across files
Keep module top-level clean	Running side effects on import

The original post is here.

Slotted classes with slots in Python

Heval Hazal Kurt — Tue, 30 Sep 2025 18:01:53 +0000

When we build backend systems in Python, performance isn't always our first concern. But sometimes, especially when you have thousands or even millions of objects in memory like API response models, simulation agents, or data processing pipelines, memory usage and speed start to matter. One of the lesser-known Python features that can help in such cases is __slots__.

In this blog, we'll explore __slots__ from beginner level to more advanced use cases, with clear examples and backend-oriented use cases.

What is `slots`?

In Python, every object by default stores its attributes in a special dictionary called __dict__. This dictionary allows us to dynamically add, remove, or modify attributes at runtime.

class User:
    def __init__(self, name, email):
        self.name = name
        self.email = email

u = User("Alice", "alice@example.com")
u.age = 30  # works just fine

But this flexibility comes at a cost. Every instance carries a dynamic dictionary, which adds memory overhead and makes attribute access a tiny bit slower. That's where __slots__ comes in. __slots__ lets you define a fixed set of attributes for a class. When used, Python doesn’t create a __dict__ for each instance, reducing memory usage.

class SlimUser:
    __slots__ = ['name', 'email']

    def __init__(self, name, email):
        self.name = name
        self.email = email

Now, trying to add a new attribute:

s = SlimUser("Bob", "bob@example.com")
s.age = 25  # AttributeError: 'SlimUser' object has no attribute 'age'

Why Should You Care?

In backend systems, we often work with many lightweight objects:

API response models
Background job data containers
DTOs (Data Transfer Objects)
Caching layers

In these cases, saving even a few bytes per object can scale into megabytes or more.

Example: API Models

class Product:
    def __init__(self, id, name, price):
        self.id = id
        self.name = name
        self.price = price

Suppose you're loading 1 million Product instances into memory for caching. Using __slots__:

class SlimProduct:
    __slots__ = ['id', 'name', 'price']

    def __init__(self, id, name, price):
        self.id = id
        self.name = name
        self.price = price

Using sys.getsizeof() won't show the full memory benefit because it only shows shallow size, but if you compare .__dict__ and .__slots__ attributes or use tools like pympler or tracemalloc will show significant reduction when objects are deeply nested.

How `slots` Works Under the Hood

When you use __slots__, Python internally creates a more static structure like a C struct instead of a dynamic dictionary. It uses descriptors and a slot table to manage attribute access.

Benefits:

Reduced memory usage per object
Slightly faster attribute access
Prevents accidental addition of unexpected attributes

Drawbacks:

No dynamic attribute assignment
Can't easily use pickling without extra steps
Subclassing can be tricky (see below)

Combining `slots` and Inheritance

Slotted classes can't be freely combined like regular ones. If you subclass a slotted class, you need to define __slots__ again even if it's empty.

class Base:
    __slots__ = ['id']

class Child(Base):
    __slots__ = ['name']

If you forget to redefine __slots__, Python will revert to using __dict__ in the subclass.

You can also include __dict__ in the slots explicitly if you want partial flexibility:

class PartiallyDynamic:
    __slots__ = ['id', '__dict__']

`@dataclass` with `slots=True`

Python 3.10+ allows using __slots__ automatically with dataclasses:

from dataclasses import dataclass

@dataclass(slots=True)
class Product:
    id: int
    name: str
    price: float

This is much cleaner and combines the benefits of dataclasses like auto-generated __init__, __repr__, etc. with memory savings.

Caching API Responses

Suppose you're building a high-throughput API that returns lots of small JSON records from Redis or a database. Each record is parsed into a Python object.

class CachedItem:
    __slots__ = ['id', 'category', 'value']

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

This keeps your memory usage lean, especially if you're storing thousands of these in memory. You can even combine __slots__ with __slots__ + property to make fields read-only:

class ImmutableItem:
    __slots__ = ['_id']

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

    @property
    def id(self):
        return self._id

When Not to Use `slots`

Don’t use __slots__ if:

You rely on libraries that dynamically add attributes like some ORMs or serializers
You need full pickling support
You're writing code that heavily depends on __dict__ introspection

It’s a tool, not a silver bullet. Use it when profiling shows memory usage is actually a concern.

Summary

__slots__ is a powerful but often overlooked feature in Python that can help reduce memory usage and improve attribute access performance in certain use cases. Especially in backend systems where you handle lots of structured but repetitive objects like response models or cached entities, slotted classes can provide measurable performance benefits.

Use them with care, test them in your architecture, and always validate with profiling tools before optimizing prematurely.

The original post is here.

How the GIL Affects Real Python Workloads

Heval Hazal Kurt — Thu, 25 Sep 2025 15:56:34 +0000

If you’ve ever tried to speed up your Python application by adding threads, only to see... nothing change. Well, welcome to the world of the Global Interpreter Lock (GIL). In this post, we’re going to break down how the GIL affects concurrency performance, especially in real-life backend workloads.

What’s the GIL?

The Global Interpreter Lock is a mutex that prevents multiple native threads from executing Python bytecodes at once in the CPython interpreter. It’s like a nightclub bouncer: only one thread can enter the Python bytecode dancefloor at a time even if there’s space for more. This means that:

Threads in Python aren’t truly concurrent when doing CPU work.
You don’t get free performance gains just by spawning threads for heavy computation.
I/O-heavy code can still benefit from threading, because the GIL is released during I/O.

CPU-Bound vs I/O-Bound: Why It Matters

Let’s define these first:

CPU-bound: Code that mainly uses CPU cycles like data crunching, image processing.
I/O-bound: Code that mostly waits like network requests, database calls, file I/O.

Why does this matter? Because the GIL hurts you most when your code is CPU-bound. That’s when threads fight over the lock. But for I/O-bound code, threads take turns nicely, because the GIL is released during blocking I/O.

Example #1: CPU-Bound Task (With Threads)

Let’s simulate a CPU-heavy workload using threads:

import threading
import time

COUNT = 50_000_000

def cpu_heavy():
    x = 0
    for _ in range(COUNT):
        x += 1

start = time.time()

thread1 = threading.Thread(target=cpu_heavy)
thread2 = threading.Thread(target=cpu_heavy)

thread1.start()
thread2.start()
thread1.join()
thread2.join()

print(f"Threads (CPU-bound): {time.time() - start:.2f}s")

What you’ll see: The two threads don’t make it faster. It may even take longer than running one after another.

Why? They’re both fighting for the GIL. Only one can do actual Python work at a time.

Example #2: CPU-Bound Task (With Multiprocessing)

Now let’s try the same workload using multiprocessing:

from multiprocessing import Process
import time

COUNT = 50_000_000

def cpu_heavy():
    x = 0
    for _ in range(COUNT):
        x += 1

start = time.time()

p1 = Process(target=cpu_heavy)
p2 = Process(target=cpu_heavy)

p1.start()
p2.start()
p1.join()
p2.join()

print(f"Processes (CPU-bound): {time.time() - start:.2f}s")

Now it’s much faster! Each process gets its own GIL and memory space — so they can run in parallel across CPU cores.

Example #3: I/O-Bound Task (With Threads)

Let’s simulate a real backend workload — calling a slow API:

import threading
import time
import requests

URL = "https://httpbin.org/delay/2"  # waits 2 seconds before replying

def fetch():
    response = requests.get(URL)
    print(response.status_code)

start = time.time()

threads = [threading.Thread(target=fetch) for _ in range(5)]

for t in threads:
    t.start()
for t in threads:
    t.join()

print(f"Threads (I/O-bound): {time.time() - start:.2f}s")

Even though each request takes 2 seconds, the whole program finishes in ~2 seconds, not 10.

Why? Because requests.get() blocks on I/O and releases the GIL, allowing other threads to run.

Threads Work Well With I/O

In backend APIs, you often:

Call other APIs
Talk to databases
Read files

These are all I/O-bound, so threading can actually help even with the GIL. For example, a simple FastAPI endpoint like:

@app.get("/status")
def get_status():
    requests.get("https://a-service.com/ping")
    return {"status": "ok"}

Can scale better under concurrent users if served by a thread-based ASGI server like Uvicorn with workers.

asyncio vs multiprocessing vs threading

Task Type	Best Tool	Why
CPU-bound	multiprocessing	Avoids the GIL by using processes
I/O-bound	threading / asyncio	GIL released during I/O
Mixed	Split workloads	Use threads for I/O, processes for CPU

Summary

Python threads won’t help you speed up CPU-heavy code because of the GIL.
For CPU-bound work, use multiprocessing, or call out to C extensions that release the GIL.
For I/O-heavy work, Python threads (or asyncio) are great.
Benchmark your own code before optimizing. You might be blaming the wrong thing.

The original post is here.

Implementing Singleton with Async/Await in Python

Heval Hazal Kurt — Mon, 22 Sep 2025 15:54:30 +0000

The Singleton pattern is one of the most well-known design patterns in software development. It ensures that a class has only one instance and provides a global point of access to it. In synchronous Python, this is fairly straightforward. But when you step into the world of asynchronous programming, things get a bit trickier.

In this blog post, we’ll start with the basics of the Singleton pattern, then move into the async/await world, and finally explore advanced usage patterns and real-life backend scenarios. We’ll also highlight common pitfalls and how to avoid them.

The Basics: What is a Singleton?

A Singleton is a class that can only have one instance throughout the lifetime of an application. In Python, this is usually implemented by overriding the __new__ method or using metaclasses.

Classic Singleton (Synchronous)

class Singleton:
    _instance = None

    def __new__(cls):
        if cls._instance is None:
            cls._instance = super().__new__(cls)
        return cls._instance

This pattern works fine when everything is synchronous. But what happens if you need to initialize the singleton asynchronously, like when making a database connection?

Enter Asynchronous Python

Asynchronous Python allows you to write non-blocking code using async and await. It’s perfect for I/O-bound tasks like API calls, database queries, or file operations. But here’s the catch: you can’t await inside __new__ or __init__, because they're not async functions. So how do you create an async-aware Singleton?

Async Singleton Pattern

Let’s say we want to create a Singleton that manages a database connection. The connection setup is asynchronous. For example using an async PostgreSQL client.

Example 1: Async Database Connector Singleton

import asyncio

class AsyncDBConnector:
    _instance = None
    _lock = asyncio.Lock()

    def __init__(self):
        self.connection = None

    @classmethod
    async def get_instance(cls):
        if cls._instance is None:
            async with cls._lock:
                if cls._instance is None:
                    instance = cls()
                    await instance._connect()
                    cls._instance = instance
        return cls._instance

    async def _connect(self):
        # Simulate async DB connection
        await asyncio.sleep(1)
        self.connection = "Connected to DB"

Why it works:

We use a class method get_instance to create the instance.
We wrap it with a lock to ensure thread safety in a multi-tasking environment.
The _connect method is async and performs the setup.

Usage:

async def main():
    db = await AsyncDBConnector.get_instance()
    print(db.connection)

asyncio.run(main())

Example 2: Singleton Config Loader

Let’s build a singleton config loader that reads secrets from an external async API like AWS Secrets Manager.

class ConfigManager:
    _instance = None
    _lock = asyncio.Lock()

    def __init__(self):
        self.config = {}

    @classmethod
    async def get_instance(cls):
        if cls._instance is None:
            async with cls._lock:
                if cls._instance is None:
                    instance = cls()
                    await instance._load_config()
                    cls._instance = instance
        return cls._instance

    async def _load_config(self):
        await asyncio.sleep(0.5)  # Simulate network request
        self.config = {
            "DATABASE_URL": "postgresql://user:pass@host/db",
            "API_KEY": "abc123xyz"
        }

# Usage
async def main():
    config = await ConfigManager.get_instance()
    print(config.config["API_KEY"])

asyncio.run(main())

Using Async Singleton in FastAPI

FastAPI is one of the most popular async web frameworks in Python. It thrives on non-blocking I/O and dependency injection. Let’s see how you can integrate an async Singleton pattern into a FastAPI app.

Use Case: Shared Redis Client or DB Connection

Imagine you have a Redis connection that should be initialized once and reused across all endpoints.

from fastapi import FastAPI, Depends
import asyncio

class RedisClient:
    _instance = None
    _lock = asyncio.Lock()

    def __init__(self):
        self.connection = None

    @classmethod
    async def get_instance(cls):
        if cls._instance is None:
            async with cls._lock:
                if cls._instance is None:
                    instance = cls()
                    await instance._connect()
                    cls._instance = instance
        return cls._instance

    async def _connect(self):
        await asyncio.sleep(1)
        self.connection = "Simulated Redis Connection"

# Dependency wrapper
async def get_redis_client() -> RedisClient:
    return await RedisClient.get_instance()

# FastAPI app
app = FastAPI()

@app.get("/status")
async def status(redis: RedisClient = Depends(get_redis_client)):
    return {"status": "ok", "redis": redis.connection}

get_redis_client() is declared as an async dependency.
The Singleton instance is resolved on demand and shared afterward.
This is perfect for Redis, PostgreSQL, and custom HTTP clients like aiohttp or httpx.

Common Pitfalls

1. Trying to `await` in `init`

This will fail:

class BadExample:
    def __init__(self):
        await self.setup()  # SyntaxError

You can't await inside __init__. Use a separate async setup method.

2. Not Using a Lock

If multiple coroutines call get_instance() at the same time, you might end up with multiple instances. Always protect instantiation with an asyncio.Lock() to ensure thread safety.

A Few Tips

Make Singleton Test-Friendly

Sometimes it’s useful to reset or override the Singleton during testing.

@classmethod
def reset_instance(cls):
    cls._instance = None

Avoid Global State

Even with Singletons, be cautious not to abuse them as global variables. It’s best to inject them where needed like as constructor args.

Lazy Initialization

Delay the heavy work until it's really needed. This keeps startup time low.

Wrapping Up

Singletons in async Python aren’t hard, but they do require you to rethink how and when your object is created. The key takeaway is: move all await logic out of __init__ and into an async method, and make sure to guard instance creation with an asyncio.Lock().

Used right, an async Singleton can be a great tool for managing shared resources like DB connections, config loaders, and API clients in modern backend applications.

The original post is here.

Understanding Async Context Managers in Python

Heval Hazal Kurt — Thu, 17 Jul 2025 15:52:37 +0000

When working with asynchronous code in Python, you're probably familiar with async def, await, and maybe even tools like aiohttp or asyncpg. But if you've ever wondered how to manage resources cleanly and safely in async code, then it's time to meet a powerful tool: the async context manager.

In this post, we’ll take a deep dive into what async context managers are, why they matter, and how to use them effectively in real-world backend applications.

What Is a Context Manager Again?

Before we dive into the async version, let’s briefly recall what a context manager is in general. In Python, context managers are commonly used with the with statement to manage setup and teardown logic:

with open('log.txt', 'w') as f:
    f.write("Logging something important.")

The file is automatically closed once the block ends even if an error occurs. This pattern is clean and safe.

Why Do We Need Async Context Managers?

The traditional with block works fine for synchronous code. But what if your resource like a database connection, network socket, or HTTP session, needs to be handled asynchronously? That’s where async context managers come in. They’re used with async with, and they allow you to:

Await asynchronous setup/teardown.
Manage resources like connections in async code.
Avoid race conditions and resource leaks.

How Async Context Managers Work

You use async with to enter an asynchronous context:

class AsyncLogger:
    async def __aenter__(self):
        print("Async Enter")
        return self

    async def __aexit__(self, exc_type, exc_val, tb):
        print("Async Exit")

async def main():
    async with AsyncLogger():
        print("Inside block")

asyncio.run(main())

So what’s happening here?

__aenter__: Think of it as an async version of __enter__. You can await things here.
__aexit__: Similar to __exit__, but awaitable.

Backend Example 1: Managing an Async HTTP Session with aiohttp

Let’s say you’re fetching data from a REST API in an async backend service:

import aiohttp
import asyncio

async def fetch_data():
    async with aiohttp.ClientSession() as session:
        async with session.get("https://api.example.com/data") as response:
            data = await response.json()
            print(data)

# asyncio.run(fetch_data())

Why this is great:

The session and request are both async context managers.
They’re automatically closed and cleaned up.
No need to manually close connections.

Backend Example 2: Async Database Connection Pool

Let’s say you're building a FastAPI app that talks to PostgreSQL using asyncpg:

import asyncpg
from fastapi import FastAPI

app = FastAPI()

@app.on_event("startup")
async def startup():
    app.state.pool = await asyncpg.create_pool(database="testdb")

@app.on_event("shutdown")
async def shutdown():
    await app.state.pool.close()

@app.get("/users")
async def get_users():
    async with app.state.pool.acquire() as conn:
        rows = await conn.fetch("SELECT * FROM users")
        return [dict(row) for row in rows]

Why use async with for DB?

Automatically releases connections back to the pool.
Prevents DB connection leaks.
Keeps code clean and easy to maintain.

Building Your Own Async Context Manager with `contextlib`

You can also build async context managers easily using contextlib.asynccontextmanager:

from contextlib import asynccontextmanager

@asynccontextmanager
async def temporary_file():
    print("Setting up async resource")
    yield "/tmp/temp.txt"
    print("Cleaning up async resource")

async def main():
    async with temporary_file() as path:
        print(f"Using temp file at {path}")

# asyncio.run(main())

This approach is simpler and cleaner than defining a full class with __aenter__/__aexit__ when all you need is a quick setup/teardown pattern.

Advanced Patterns

Nesting Async Context Managers

You can nest multiple async contexts just like sync ones:

async with aiohttp.ClientSession() as session:
    async with session.get(url) as response:
        data = await response.text()

Or combine them with async with and commas:

async with manager1(), manager2():
    ...

Combining with `async for`

async with some_streaming_context() as stream:
    async for chunk in stream:
        await process(chunk)

Useful when reading big files or streaming API responses.

Using Inside Dependency Injection (FastAPI Example)

@asynccontextmanager
async def get_db():
    async with db_pool.acquire() as conn:
        yield conn

@app.get("/products")
async def read_products(db = Depends(get_db)):
    rows = await db.fetch("SELECT * FROM products")
    return rows

Common Pitfalls

Pitfall	Explanation
Forgetting `await`	`__aenter__` and `__aexit__` are coroutines. You must `await` them using `async with`.
Blocking calls inside `async with`	Avoid using synchronous (blocking) code inside async blocks. It kills concurrency.
Not releasing resources	If you don’t use `async with`, you might forget to close sessions, which can lead to memory or connection leaks.

Cheat Sheet

# Basic Structure
class MyAsyncManager:
    async def __aenter__(self): ...
    async def __aexit__(self, exc_type, exc, tb): ...

# Shortcut with contextlib
@asynccontextmanager
async def my_manager():
    yield resource

# Usage
async with my_manager() as res:
    await do_something(res)

Final Thoughts

Async context managers are a must-know tool for writing clean, safe, and efficient asynchronous code in modern Python. Whether you're dealing with HTTP clients, database pools, or temporary async resources, they help you stay in control without clutter.

If you're writing backend services with FastAPI, aiohttp, or Quart, mastering async context managers will make your architecture more robust and professional.

Behind the Underscores EP13: Metaprogramming Methods (class, bases, mro, instancecheck)

Heval Hazal Kurt — Fri, 11 Jul 2025 16:26:53 +0000

Metaprogramming in Python is like programming about programming. It means writing code that can change how other code behaves. Sounds deep? It is. But it's also powerful. In this post, we'll break down some of the most important metaprogramming methods in Python. These include __class__, __bases__, __mro__, __instancecheck__, and __subclasshook__. We’ll keep things practical and show how they might be useful in real backend development scenarios.

First, What Is a Metaclass?

A metaclass is simply the class of a class. Just like objects are created from classes, classes themselves are created from metaclasses.

Think of it this way:

🧱 You use a class to build objects.
🛠️ Python uses a metaclass to build classes.

By default, Python uses a built-in metaclass called type, but you can define your own to control how classes behave when they’re created.

Here’s a super simple example:

class MyMeta(type):
    def __new__(cls, name, bases, dct):
        print(f\"Creating class: {name}\")
        return super().__new__(cls, name, bases, dct)

class MyClass(metaclass=MyMeta):
    pass

# Output: Creating class: MyClass

As you can see, MyMeta intercepted the moment MyClass was being defined and injected its own logic. That’s the core idea.

What’s Python’s Default Metaclass Structure?

Like I mentioned before, in Python, the default metaclass is type. Every class you define is actually an instance of type, unless you say otherwise.

class A:
    pass

print(type(A))  # <class 'type'>

Even built-in classes follow this structure:

print(type(int))     # <class 'type'>
print(type(object))  # <class 'type'>

So what does type actually do? It:

Creates new classes when you define them
Handles the __mro__, __bases__, and other class-level mechanics
Serves as the parent of all metaclasses

Unless you explicitly specify another metaclass, Python will always fall back to type. This is what makes metaprogramming possible in the first place. You’re building on top of Python’s default behavior and customizing it to your needs.

Now, let’s look at how we can make them custom for our codes.

1. `class`: Who Are You Really?

The __class__ attribute tells you the class of an instance. It’s a simple yet powerful way to inspect objects at runtime.

Example: Debugging API Payloads

Imagine you're working on a Flask or FastAPI backend. You receive an object that should be a UserPayload, but you want to double-check.

class UserPayload:
    pass

data = UserPayload()
print(data.__class__)  # <class '__main__.UserPayload'>

Real-life use

Let’s say you log incoming data types for debugging:

def log_type(obj):
    print(f"Received object of type: {obj.__class__.__name__}")

2. `bases`: Know Your Parents

This attribute gives you the immediate parent classes of a class. It’s like checking a family tree.

Example: Plugin System

Say you’re building a plugin system and you want to validate that a plugin inherits from BasePlugin:

class BasePlugin:
    pass

class MyPlugin(BasePlugin):
    pass

print(MyPlugin.__bases__)  # (<class '__main__.BasePlugin'>,)

Real-life use

When auto-discovering classes for registration:

if BasePlugin in MyPlugin.__bases__:
    register_plugin(MyPlugin)

3. `mro`: Method Resolution Order

This is how Python decides which method to call when there are multiple inheritance paths. You can inspect it to understand how your code will behave.

Example: Service Layer Conflict Resolution

In a layered service architecture, if two parent classes implement the same method, __mro__ helps resolve ambiguity.

class AuthService:
    def execute(self):
        print("Auth logic")

class LoggingService:
    def execute(self):
        print("Logging logic")

class UserService(AuthService, LoggingService):
    pass

print([cls.__name__ for cls in UserService.__mro__])
# ['UserService', 'AuthService', 'LoggingService', 'object']

Python will call AuthService.execute() first.

4. `instancecheck`: Redefining `isinstance()`

You can override how isinstance() works by using a metaclass and implementing __instancecheck__.

Example: Duck Typing Microservices

In microservices, you often care about behavior, not type. Suppose anything with a .run() method is a valid Job:

class JobMeta(type):
    def __instancecheck__(cls, instance):
        return callable(getattr(instance, 'run', None))

class Job(metaclass=JobMeta):
    pass

class EmailJob:
    def run(self):
        print("Sending email")

print(isinstance(EmailJob(), Job))  # True

Even though EmailJob doesn’t inherit from Job, it’s considered an instance.

5. `subclasshook`: Virtual Subclasses

This is used when you want issubclass() to return True even when there is no inheritance as long as the class behaves like it should.

Example: Abstract Base Classes in a Backend

Let’s define a repository interface that all storage backends should implement:

from abc import ABCMeta

class Repository(metaclass=ABCMeta):
    @classmethod
    def __subclasshook__(cls, subclass):
        return (hasattr(subclass, 'save') and
                hasattr(subclass, 'delete'))

class SQLRepository:
    def save(self): pass
    def delete(self): pass

print(issubclass(SQLRepository, Repository))  # True

This is great when you want to enforce contracts by behavior rather than strict inheritance.

When Do We Actually Need Metaprogramming?

Most of the time, plain classes and functions will get you pretty far in Python. But metaprogramming becomes useful when your code needs to be more dynamic, self-aware, or extendable.

Here are some situations where metaprogramming methods shine:

Framework Design: If you're building your own framework like Django or FastAPI, you'll often need to hook into how classes are created or validated.
Plugin Systems: Want to load plugins automatically just by defining new classes? __subclasshook__ and __bases__ can help.
Custom Validation Rules: You might want to check if objects follow certain rules without enforcing inheritance which is great for loose coupling.
Duck Typing by Behavior: Instead of checking inheritance, you check if an object behaves a certain way like having a .run() method.
Debugging or Logging: Use __class__, __mro__, and others to inspect what kind of object you're dealing with at runtime.

In short, when you want to make Python smarter about how it sees and uses classes or object, this is when metaprogramming helps.

When Should We Be Careful Using Them?

Just because you can use metaprogramming doesn’t mean you always should. These tools are powerful, but they come with sharp edges.

Here’s when you should take a step back:

Readability Drops: Overusing metaclasses and custom hooks can make code really hard to follow for other developers and even future you.
Debugging Becomes Harder: If isinstance() or issubclass() doesn’t behave normally, that can cause confusion and bugs that are tough to trace.
Performance Overhead: Dynamically checking attributes in __instancecheck__ or __subclasshook__ might slow things down if used on large datasets or high-traffic systems.
Third-Party Conflicts: Some libraries or tools may expect default behaviors, so customizing too much might break integrations.

Use them like spices: a pinch here and there can make your code elegant. Overdo it, and you’ll ruin the dish.

Final Thoughts

Metaprogramming methods like __class__, __bases__, __mro__, __instancecheck__, and __subclasshook__ are not just abstract ideas. They give you fine-grained control over how your code behaves, especially in large-scale backend systems where flexibility, extensibility, and loose coupling are essential.

Use them wisely, and you’ll unlock the ability to write smarter, more adaptive Python code.

Behind the Underscores EP12: Descriptor Protocol (get, set, delete)

Heval Hazal Kurt — Thu, 10 Jul 2025 14:35:09 +0000

Python is full of powerful features that let you write clean, reusable, and elegant code. One of these features, often misunderstood or underused, is the descriptor protocol. Descriptors let you hook into attribute access and build flexible, reusable behaviors around it. They're used heavily behind the scenes in properties, class methods, static methods, and even Django ORM models.

In this blog post, we’ll break down the descriptor protocol special methods: __get__, __set__, and __delete__, and see how they’re useful in backend development.

What Is a Descriptor?

A descriptor is simply a class that implements any of the following methods:

__get__(self, instance, owner)
__set__(self, instance, value)
__delete__(self, instance)

Once a descriptor class is assigned as a class attribute, it controls access to that attribute. This allows you to customize what happens when someone gets, sets, or deletes an attribute from an instance of the owner class.

The Three Special Methods

1. `get`: Controls how an attribute is read

def __get__(self, instance, owner):
    # Return the value to be used when the attribute is accessed

instance: the instance accessing the attribute
owner: the class of the instance

2. `set`: Controls how an attribute is written

def __set__(self, instance, value):
    # Handle setting a new value to the attribute

value: the value being assigned to the attribute

3. `delete`: Controls what happens when an attribute is deleted

def __delete__(self, instance):
    # Handle deletion of the attribute

Now, let’s explore them in a few real-life backend examples.

Example 1: Using a Descriptor in a Product Tag System

Imagine you’re building a backend for an e-commerce site. Each product can have tags, and these tags store various metadata like value, shape, and name. Internally, this data lives in a data object, but you want to make access clean and consistent on the main Tag class.

class TagDataDescriptor:
    def __init__(self, attr):
        self.attr = attr

    def __get__(self, tag, owner):
        return getattr(tag.data, self.attr)

    def __set__(self, tag, value):
        setattr(tag.data, self.attr, value)

class Tag:
    value = TagDataDescriptor('value')
    shape = TagDataDescriptor('shape')
    name = TagDataDescriptor('name')

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

class TagData:
    def __init__(self, value, shape, name):
        self.value = value
        self.shape = shape
        self.name = name

# Usage
raw_data = TagData("sale", "circle", "Discount")
tag = Tag(raw_data)

print(tag.value)   # Prints: sale
tag.shape = "square"
print(tag.data.shape)  # Prints: square

So, What’s Happening

When you do tag.value, the descriptor’s __get__ method is triggered.
It fetches the actual data from tag.data.value.
When you set tag.shape = "square", the descriptor forwards it to tag.data.shape = "square".

Why It’s Useful in Backend Code

You keep your API clean and simple.
You decouple the internal data structure from the public interface.
You can change how the data is stored later without touching external code.

Example 2: Validating Configuration

In this second example, let’s say you’re managing application settings like port numbers or environment variables. You want to validate values when they’re set, but keep your class definitions neat.

class PortValidator:
    def __get__(self, instance, owner):
        return instance.__dict__.get('_port')

    def __set__(self, instance, value):
        if not (1024 <= value <= 65535):
            raise ValueError("Port must be between 1024 and 65535")
        instance.__dict__['_port'] = value

    def __delete__(self, instance):
        raise AttributeError("Port can't be deleted")

class AppConfig:
    port = PortValidator()

    def __init__(self, port):
        self.port = port

# Usage
config = AppConfig(8080)
print(config.port)  # 8080
config.port = 70000  # Raises ValueError

So, What’s Happening Again

__set__ checks that the port is within a valid range.
__get__ fetches the value from instance’s __dict__.
__delete__ blocks deletion to avoid broken config states.

And Why It’s Useful in Backend Code

You enforce data validation at the attribute level.
You avoid repeating validation logic in multiple places.
You define consistent rules for critical settings.

Final Thoughts

The descriptor protocol is a hidden gem in Python that can supercharge your backend design patterns. By hooking into __get__, __set__, and __delete__, you can build smart attributes that:

Forward access to other layers like data models
Automatically validate and control data
Clean up repetitive property definitions

Understanding descriptors might take a little practice, but once you get used to them, they become a very natural and Pythonic way to organize your code.

The original post is here.

Behind the Underscores EP11: Callable Objects: call

Heval Hazal Kurt — Mon, 07 Jul 2025 12:49:58 +0000

When we think of calling something in Python, the first thing that comes to mind is usually a function. But Python gives us the power to go a step further: objects can behave like functions if they implement a special method called __call__. This concept might seem a bit strange at first, but once you understand how it works, you’ll find it incredibly useful, especially for building clean, modular backend systems.

In this blog post, we’ll dive deep into the __call__ method. We'll explore:

What __call__ really does under the hood
Why and when you should use it
The potential pitfalls to watch out for
Realistic backend examples

Let’s get started.

What is the `call` Method?

In Python, every function is an object. And just like functions, any object that implements the __call__ method can be used with parentheses to make it behave like a function:

class Greeter:
    def __init__(self, name):
        self.name = name

    def __call__(self, greeting="Hello"):
        return f"{greeting}, {self.name}!"

hello_john = Greeter("John")
print(hello_john())           # Output: Hello, John!
print(hello_john("Hi"))       # Output: Hi, John!

Here, hello_john is an instance of Greeter, but thanks to __call__, we can treat it like a function.

Why Would You Use `call`?

You might wonder: “Why not just use a regular function?”. That’s a fair question. Here are some reasons why using __call__ can be a better choice in certain situations:

1. Encapsulation of State

Classes let you store data, or we say state, and behavior together. With __call__, you can package that logic in a neat callable form.

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

    def __call__(self, number):
        return self.factor * number

triple = Multiplier(3)
print(triple(10))  # Output: 30

2. Cleaner Dependency Injection

In frameworks like FastAPI or Flask, you may want to inject behavior or data as a callable. Making your class instance callable makes the integration seamless.

3. Custom Middleware or Pipelines

If you're building your own middleware system, having callable objects makes it easier to write and chain operations.

When Not to Use `call`

While __call__ can be powerful, it can also lead to confusion or overengineering if used improperly.

Readability concerns: Readers of your code might not expect that an instance behaves like a function. This can hurt code clarity.
Debugging difficulty: Errors in a __call__ implementation might be harder to track if your class hides too much logic inside it.
Unnecessary abstraction: Sometimes a simple function is better. Don’t wrap everything in a class just because you can.

Rule of Thumb

Use __call__ when your object:

Maintains state that’s useful across calls
Needs to fit into APIs that expect callables
Has a behavior that makes sense as a single primary action

Backend Example #1: Request Logger Middleware

Imagine you’re building a custom logging middleware for a web server. You want to log the request method and path.

class RequestLoggerMiddleware:
    def __init__(self, app):
        self.app = app

    async def __call__(self, scope, receive, send):
        if scope["type"] == "http":
            method = scope["method"]
            path = scope["path"]
            print(f"[LOG] {method} request to {path}")

        await self.app(scope, receive, send)

This can be used in a FastAPI or Starlette app like this:

app.add_middleware(RequestLoggerMiddleware)

Because the middleware instance is callable, it fits perfectly into the ASGI lifecycle.

Backend Example #2: Authorization Checker

Let’s say you need to check if a user has a specific role before allowing access to a route.

class RoleChecker:
    def __init__(self, allowed_roles):
        self.allowed_roles = allowed_roles

    def __call__(self, user):
        if user.role not in self.allowed_roles:
            raise PermissionError("Access denied")
        return True

check_admin = RoleChecker(["admin"])

user = User(role="guest")
check_admin(user)  # Raises PermissionError

This is especially useful when you’re designing reusable validation or guard components.

Summary: The Power of `call`

The __call__ method turns your objects into callable powerhouses. It combines the simplicity of functions with the structure of classes, giving you the best of both worlds. But like any powerful tool, it should be used thoughtfully.

The original post is here.

Behind the Underscores EP10: Context Management (enter, exit)

Heval Hazal Kurt — Tue, 01 Jul 2025 17:50:13 +0000

Have you ever opened a file in Python, wrote something, and forgot to close it? Maybe it didn’t break your program, but it’s not good practice. Leaving files or network connections open can cause resource leaks, meaning you’re using up system memory or leaving a file locked unnecessarily. That’s where context managers come in. They handle the “setup and teardown” automatically so you can focus on your logic without worrying about the cleanup.

This blog will guide you through:

What a context manager is
How __enter__ and __exit__ work
Real-life use cases and examples
How to write your own context managers both class-based and function-based

Let’s dive in!

What Is a Context Manager?

A context manager is a Python object that properly manages resources like files, network connections, or database sessions. It makes sure things are set up when you enter a block of code and cleaned up when you leave it, even if something goes wrong.

You’ve already used one before:

with open("myfile.txt", "w") as f:
    f.write("Hello, world!")

What this does behind the scenes:

Python calls f = open(...), then f.__enter__()
It runs your f.write(...) inside the with block
When the block is done or crashes, it calls f.__exit__() to close the file

You didn’t have to write a try/finally block. Python cleaned up for you.

The `enter` and `exit` Methods

To create a context manager yourself, you need a class that defines two special methods:

class MyContext:
    def __enter__(self):
        # Setup code here
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        # Cleanup code here
        pass

Let’s see this in action with a simple logger.

Example 1: A Simple Logging Context Manager

import time

class Timer:
    def __enter__(self):
        self.start = time.time()
        print("Starting the timer...")
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        end = time.time()
        print(f"Elapsed time: {end - self.start:.2f} seconds")

Usage:

with Timer():
    # Simulate work
    time.sleep(1.5)

Output:

Starting the timer...
Elapsed time: 1.50 seconds

Even if there’s an error inside the block, __exit__ still runs which is great for cleanup.

Real-Life Use Cases

Let’s take this a bit further. Here are some practical real-world problems you can solve with custom context managers.

1. Automatically Closing Resources

Imagine you're working with file handles, network sockets, or database connections. You need to ensure they're closed no matter what happens.

Instead of writing:

db = connect_to_db()
try:
    do_something(db)
finally:
    db.close()

Use a context manager:

with connect_to_db() as db:
    do_something(db)

2. Temporarily Change Working Directory

You might want to run a script in a different folder temporarily and go back automatically.

import os

class ChangeDirectory:
    def __init__(self, path):
        self.new_path = path
        self.original_path = os.getcwd()

    def __enter__(self):
        os.chdir(self.new_path)

    def __exit__(self, exc_type, exc_value, traceback):
        os.chdir(self.original_path)

Usage:

print("Before:", os.getcwd())

with ChangeDirectory("/tmp"):
    print("Inside:", os.getcwd())

print("After:", os.getcwd())

It cleanly returns you to your original path. Great for file-heavy automation scripts.

3. Thread Locking in Multithreading

Working with threading.Lock()?

import threading

lock = threading.Lock()

# Instead of this:
lock.acquire()
try:
    do_something()
finally:
    lock.release()

# Do this:
with lock:
    do_something()

The lock is automatically released after the block.

4. Suppressing Output Temporarily

Sometimes you use a noisy library that prints too much. You can silence it:

import sys
import os
from contextlib import contextmanager

@contextmanager
def suppress_output():
    original_stdout = sys.stdout
    sys.stdout = open(os.devnull, 'w')
    try:
        yield
    finally:
        sys.stdout.close()
        sys.stdout = original_stdout

Usage:

with suppress_output():
    print("This won't show up.")

This is handy when running external tools or verbose APIs.

5. Retrying on Failure

Want to retry a risky operation automatically?

class Retry:
    def __init__(self, retries):
        self.retries = retries

    def __enter__(self):
        return self

    def __exit__(self, exc_type, exc_value, traceback):
        if exc_type and self.retries > 0:
            self.retries -= 1
            return True  # Suppress the error and retry
        return False  # Let the exception propagate if out of retries

Wrap in a loop:

while True:
    with Retry(3) as r:
        try:
            risky_operation()
            break
        except:
            if r.retries == 0:
                raise

You just built a mini fault-tolerant system!

Final Thoughts

Context managers are one of Python’s most powerful but underused features. Once you start using them, you'll find dozens of places where they clean up your code and prevent bugs especially around resources, cleanup, and state changes.

Use them when:

You need something to be cleaned up after use
You're dealing with files, sockets, locks, or temporary state
You want readable and bug-resistant code

Start small. Try writing one or two yourself. You’ll see how easy and useful they really are.

Behind the Underscores EP09: Attribute Access (getattr, getattribute, setattr, delattr)

Heval Hazal Kurt — Thu, 26 Jun 2025 16:41:51 +0000

If you’ve been working with Python for a while, you’ve probably used objects and attributes all the time:

class User:
    def __init__(self, name):
        self.name = name

u = User("Alice")
print(u.name)  # Accessing the 'name' attribute

Simple enough, right? But under the hood, Python gives you some powerful tools to customize what happens when you access, set, or delete attributes. These tools are special methods like __getattr__, __getattribute__, __setattr__, and __delattr__.

Let’s dive into what they are, what they do, and when and how to use them with real-world use cases.

First: What Is an Attribute?

An attribute is just a variable that belongs to an object. When you write obj.x, x is the attribute. In classes, attributes are usually things like name, email, age, etc. You get or set them using dot notation.

Attribute Access Internals

Python handles attribute access in this order:

Check the instance dictionary (__dict__)
Look in the class and its base classes
If not found, call __getattr__ if it exists

But when you want to take control over how attribute access behaves, you can override four methods:

Method	When it Runs	Common Use Cases
`__getattribute__`	Always on attribute access	Logging, access control, wrappers
`__getattr__`	Only if attribute is missing	Lazy loading, proxies, fallbacks
`__setattr__`	On every attribute assignment	Validation, transformation, logging
`__delattr__`	On every attribute deletion	Protection, cleanup, auditing

Let’s go through them one by one.

`getattribute`: Called Every Time You Access an Attribute

class Demo:
    def __getattribute__(self, name):
        print(f"Getting attribute: {name}")
        return super().__getattribute__(name)

This method is always called when you access any attribute on an instance. Even built-in ones like __class__.

Why use it?

Logging or debugging attribute access
Enforcing rules for access
Adding dynamic behavior

If you override __getattribute__, you must call super().__getattribute__(name) inside it. Otherwise, you'll get a recursive loop and a RecursionError.

`getattr`: Called Only If the Attribute Doesn't Exist

class Lazy:
    def __getattr__(self, name):
        print(f"{name} not found. Creating it lazily.")
        return f"Default for {name}"

This method is called only when the attribute is missing. It’s great for:

Providing defaults
Lazy-loading values
Building proxy/wrapper objects

obj = Lazy()
print(obj.anything)  # "anything" doesn’t exist so __getattr__ is triggered

It will not run if the attribute already exists!

`setattr`: Called When Setting an Attribute

class Strict:
    def __setattr__(self, name, value):
        print(f"Setting {name} = {value}")
        super().__setattr__(name, value)

Use __setattr__ when you want to:

Validate or transform inputs
Prevent or limit setting certain attributes
Automatically log changes

user = Strict()
user.age = 42  # Calls __setattr__

Just like with __getattribute__, you must call super().__setattr__ or else the value won't be stored.

`delattr`: Called When Deleting an Attribute

class Guarded:
    def __delattr__(self, name):
        print(f"Attempting to delete {name}")
        if name == "id":
            raise AttributeError("You can't delete 'id'")
        super().__delattr__(name)

This method is useful when:

You want to protect certain attributes from being deleted
You want to log or audit deletions
You need to keep cleanup logic centralized

obj = Guarded()
obj.name = "temp"
del obj.name  # Calls __delattr__

Example: Lazy Configuration Loader

Let’s say you want to load some configuration values only when they are needed:

class Config:
    def __init__(self):
        self._store = {}

    def __getattr__(self, name):
        print(f"Loading config for {name}")
        value = f"default_{name}"
        self._store[name] = value
        return value

config = Config()
print(config.db_url)   # Loads lazily
print(config.api_key)  # Loads lazily

No db_url or api_key is defined beforehand. But thanks to __getattr__, they work anyway. Look at the output.

Loading config for db_url
default_db_url
Loading config for api_key
default_api_key

Combine Methods for Power

You can combine these magic methods to create powerful behavior:

class Magic:
    def __getattribute__(self, name):
        print(f"Accessing: {name}")
        return super().__getattribute__(name)

    def __getattr__(self, name):
        print(f"'{name}' not found. Using default.")
        return 42

    def __setattr__(self, name, value):
        print(f"Setting {name} = {value}")
        super().__setattr__(name, value)

    def __delattr__(self, name):
        print(f"Deleting {name}")
        super().__delattr__(name)

This kind of setup is great for:

Wrapping APIs
Building caching layers
Creating domain-specific languages
Validating models like in frameworks

Final Thoughts

These methods may seem magical at first, but once you understand how they work, they open up a whole new level of control in your classes. Just remember:

Always call super() inside these methods unless you're intentionally breaking behavior.
Be cautious with __getattribute__, it’s very powerful and dangerous if misused.
Use these tools to build smarter, more flexible, and maintainable code.

Behind the Underscores EP08: Length and iteration Methods (len, iter, next, contains)

Heval Hazal Kurt — Wed, 25 Jun 2025 18:06:27 +0000

If you've ever used a for loop, checked if a value is in a list, or called len() on something, you've been using Python's data model. Specifically, special methods like __len__, __iter__, __next__, and __contains__. These “dunder methods” let you make your own Python objects behave like built-in types. Want your custom class to work with len(), in, or a for loop? These methods are the key.

Let’s break them down with examples, everyday explanations.

1. `len`: Make `len()` Work on Your Object

What it does:

When you call len(something), Python looks for a __len__() method under the hood.

Why it matters:

If you build a class and want len(my_obj) to return something meaningful, like how many items are inside it, you define __len__.

Example:

class ShoppingCart:
    def __init__(self):
        self.items = []

    def add_item(self, item):
        self.items.append(item)

    def __len__(self):
        return len(self.items)

cart = ShoppingCart()
cart.add_item("apple")
cart.add_item("banana")

print(len(cart))  # Output: 2

2. `iter`: Make Your Object Iterable

What it does:

This method lets Python know how to start looping over your object.

Why it matters:

With __iter__, your object can be used in a for loop, list comprehensions, or anything that expects something iterable.

Example:

class Numbers:
    def __init__(self):
        self.data = [10, 20, 30]

    def __iter__(self):
        return iter(self.data)  # Could also return a custom iterator

nums = Numbers()
for n in nums:
    print(n)  # 10 20 30

3. `next`: Define What Happens On Each Iteration Step

What it does:

This method returns the next item from your object. It’s usually paired with __iter__.

Why it matters:

If you're building a custom iterator from scratch, __next__ is where the actual “step-by-step" happens.

Example:

class Countdown:
    def __init__(self, start):
        self.current = start

    def __iter__(self):
        return self  # The object is its own iterator

    def __next__(self):
        if self.current < 0:
            raise StopIteration
        val = self.current
        self.current -= 1
        return val

for num in Countdown(3):
    print(num)  # 3 2 1 0

4. `contains`: Control How `in` Works

What it does:

This method is triggered when you write something like:

if "apple" in cart:

Why it matters:

It lets you define what it means for an item to “be inside” your object.

Example:

class ShoppingCart:
    def __init__(self):
        self.items = ["apple", "banana"]

    def __contains__(self, item):
        return item in self.items

cart = ShoppingCart()
print("banana" in cart)  # True
print("milk" in cart)    # False

If you don’t implement __contains__, Python will automatically fall back to looping over the object using __iter__. That’s helpful!

How These Work Together

Let’s look at a bigger picture. When you do this:

if "something" in my_obj:

Python tries the methods in this order:

Try __contains__.
If not available, try to iterate with __iter__ and compare each item.
If neither is available, it raises a TypeError.

When you do this:

for x in my_obj:

Python does this behind the scenes:

Calls __iter__() to get an iterator.
Repeatedly calls __next__() on the iterator.
Stops when StopIteration is raised.

Real-World Use Cases

Custom collections: Build your own data containers that behave like lists, sets, or queues.
Data wrappers: Wrap API or database results in classes that are iterable and length-aware.
Game states or UI systems: Control which components are active using __contains__.

You Don’t Always Need All of Them

You might just need __iter__ if you're building a class that behaves like a list.

You might only need __len__ if you're showing count in a UI or enforcing limits.

And sometimes, using yield and generators is even easier for iteration than managing __next__ manually.

Summary

Method	Purpose	Used by...
`__len__`	Define what `len(obj)` returns	`len()`
`__iter__`	Make object iterable	`for`, `in`, list comps
`__next__`	Get the next item in a loop	`next()`, `for`
`__contains__`	Define `in` behavior	`"x" in obj`

Wrapping Up

These special methods are like magic doors into Python’s built-in behavior. Once you learn to use them, you can make your classes feel like real native Python types. If you're building something reusable or preparing for interviews, mastering __len__, __iter__, __next__, and __contains__ is a great move.

The original post is here.

Forem: Heval Hazal Kurt

Why Composition Beats Inheritance in Large-Scale Python Systems

Inheritance vs Composition

The Problems with Inheritance in Big Codebases

1. Tight Coupling

2. Inheritance Hierarchies Get Deep and Confusing

3. Inheritance Isn’t Flexible

4. Testing Becomes Harder

Composition to the Rescue

Scenario 1: Injecting Services into API Endpoints

Scenario 2: Payments with Strategy Pattern via Composition

Scenario 3: Repository Pattern with Swappable Storage

Advantages of Composition in Production Code

So..

The Art of Scope Management in Modular Python Design

What Is “Scope” in Python?

The LEGB Rule: Python’s Scope Lookup Chain

Why Scope Matters

Rule 1: Keep Your Global Scope Clean

Use Module Scope for Reusability

Avoid Import-Time Side Effects

Advanced Scope Patterns for Large Projects

1. Dependency Injection with Scope Control

Using Classes to Encapsulate State

Factory Functions and Closures for Configurable Behavior

Clean Scope = Clean Code

Slotted classes with __slots__ in Python

What is __slots__?

Why Should You Care?

Example: API Models

How __slots__ Works Under the Hood

Combining __slots__ and Inheritance

@dataclass with slots=True

Caching API Responses

When Not to Use __slots__

Summary

How the GIL Affects Real Python Workloads

What’s the GIL?

CPU-Bound vs I/O-Bound: Why It Matters

Example #1: CPU-Bound Task (With Threads)

Example #2: CPU-Bound Task (With Multiprocessing)

Example #3: I/O-Bound Task (With Threads)

Threads Work Well With I/O

asyncio vs multiprocessing vs threading

Summary

Implementing Singleton with Async/Await in Python

The Basics: What is a Singleton?

Classic Singleton (Synchronous)

Enter Asynchronous Python

Async Singleton Pattern

Example 1: Async Database Connector Singleton

Why it works:

Usage:

Example 2: Singleton Config Loader

Using Async Singleton in FastAPI

Use Case: Shared Redis Client or DB Connection

Common Pitfalls

1. Trying to await in __init__

2. Not Using a Lock

A Few Tips

Make Singleton Test-Friendly

Avoid Global State

Lazy Initialization

Wrapping Up

Understanding Async Context Managers in Python

What Is a Context Manager Again?

Why Do We Need Async Context Managers?

How Async Context Managers Work

Backend Example 1: Managing an Async HTTP Session with aiohttp

Backend Example 2: Async Database Connection Pool

Building Your Own Async Context Manager with contextlib

Advanced Patterns

Nesting Async Context Managers

Combining with async for

Using Inside Dependency Injection (FastAPI Example)

Common Pitfalls

Cheat Sheet

Final Thoughts

Behind the Underscores EP13: Metaprogramming Methods (__class__, __bases__, __mro__, __instancecheck__)

First, What Is a Metaclass?

Slotted classes with slots in Python

What is `slots`?

How `slots` Works Under the Hood

Combining `slots` and Inheritance

`@dataclass` with `slots=True`

When Not to Use `slots`

1. Trying to `await` in `init`

Building Your Own Async Context Manager with `contextlib`

Combining with `async for`

Behind the Underscores EP13: Metaprogramming Methods (class, bases, mro, instancecheck)

1. `class`: Who Are You Really?

2. `bases`: Know Your Parents

3. `mro`: Method Resolution Order

4. `instancecheck`: Redefining `isinstance()`

5. `subclasshook`: Virtual Subclasses

Behind the Underscores EP12: Descriptor Protocol (get, set, delete)

1. `get`: Controls how an attribute is read

2. `set`: Controls how an attribute is written

3. `delete`: Controls what happens when an attribute is deleted

Behind the Underscores EP11: Callable Objects: call

What is the `call` Method?

Why Would You Use `call`?

When Not to Use `call`

Summary: The Power of `call`

Behind the Underscores EP10: Context Management (enter, exit)

The `enter` and `exit` Methods

Behind the Underscores EP09: Attribute Access (getattr, getattribute, setattr, delattr)

`getattribute`: Called Every Time You Access an Attribute

`getattr`: Called Only If the Attribute Doesn't Exist

`setattr`: Called When Setting an Attribute

`delattr`: Called When Deleting an Attribute

Behind the Underscores EP08: Length and iteration Methods (len, iter, next, contains)

1. `len`: Make `len()` Work on Your Object

2. `iter`: Make Your Object Iterable