Python Anti-Patterns Checklist

A reference checklist of common mistakes and anti-patterns in Python code. Review this before finalizing implementations to catch issues early.

When to Use This Skill

• Reviewing code before merge

• Debugging mysterious issues

• Teaching or learning Python best practices

• Establishing team coding standards

• Refactoring legacy code

Note: This skill focuses on what to avoid. For guidance on positive patterns and architecture, see the python-design-patterns skill.

Infrastructure Anti-Patterns

Scattered Timeout/Retry Logic

# BAD: Timeout logic duplicated everywhere

def fetch_user(user_id):

    try:

        return requests.get(url, timeout=30)

    except Timeout:

        logger.warning("Timeout fetching user")

        return None

def fetch_orders(user_id):

    try:

        return requests.get(url, timeout=30)

    except Timeout:

        logger.warning("Timeout fetching orders")

        return None

Fix: Centralize in decorators or client wrappers.

# GOOD: Centralized retry logic

@retry(stop=stop_after_attempt(3), wait=wait_exponential())

def http_get(url: str) -> Response:

    return requests.get(url, timeout=30)

Double Retry

# BAD: Retrying at multiple layers

@retry(max_attempts=3)  # Application retry

def call_service():

    return client.request()  # Client also has retry configured!

Fix: Retry at one layer only. Know your infrastructure's retry behavior.

Hard-Coded Configuration

# BAD: Secrets and config in code

DB_HOST = "prod-db.example.com"

API_KEY = "sk-12345"

def connect():

    return psycopg.connect(f"host={DB_HOST}...")

Fix: Use environment variables with typed settings.

# GOOD

from pydantic_settings import BaseSettings

class Settings(BaseSettings):

    db_host: str = Field(alias="DB_HOST")

    api_key: str = Field(alias="API_KEY")

settings = Settings()

Architecture Anti-Patterns

Exposed Internal Types

# BAD: Leaking ORM model to API

@app.get("/users/{id}")

def get_user(id: str) -> UserModel:  # SQLAlchemy model

    return db.query(UserModel).get(id)

Fix: Use DTOs/response models.

# GOOD

@app.get("/users/{id}")

def get_user(id: str) -> UserResponse:

    user = db.query(UserModel).get(id)

    return UserResponse.from_orm(user)

Mixed I/O and Business Logic

# BAD: SQL embedded in business logic

def calculate_discount(user_id: str) -> float:

    user = db.query("SELECT * FROM users WHERE id = ?", user_id)

    orders = db.query("SELECT * FROM orders WHERE user_id = ?", user_id)

    # Business logic mixed with data access

    if len(orders) > 10:

        return 0.15

    return 0.0

Fix: Repository pattern. Keep business logic pure.

# GOOD

def calculate_discount(user: User, orders: list[Order]) -> float:

    # Pure business logic, easily testable

    if len(orders) > 10:

        return 0.15

    return 0.0

Error Handling Anti-Patterns

Bare Exception Handling

# BAD: Swallowing all exceptions

try:

    process()

except Exception:

    pass  # Silent failure - bugs hidden forever

Fix: Catch specific exceptions. Log or handle appropriately.

# GOOD

try:

    process()

except ConnectionError as e:

    logger.warning("Connection failed, will retry", error=str(e))

    raise

except ValueError as e:

    logger.error("Invalid input", error=str(e))

    raise BadRequestError(str(e))

Ignored Partial Failures

# BAD: Stops on first error

def process_batch(items):

    results = []

    for item in items:

        result = process(item)  # Raises on error - batch aborted

        results.append(result)

    return results

Fix: Capture both successes and failures.

# GOOD

def process_batch(items) -> BatchResult:

    succeeded = {}

    failed = {}

    for idx, item in enumerate(items):

        try:

            succeeded[idx] = process(item)

        except Exception as e:

            failed[idx] = e

    return BatchResult(succeeded, failed)

Missing Input Validation

# BAD: No validation

def create_user(data: dict):

    return User(**data)  # Crashes deep in code on bad input

Fix: Validate early at API boundaries.

# GOOD

def create_user(data: dict) -> User:

    validated = CreateUserInput.model_validate(data)

    return User.from_input(validated)

Resource Anti-Patterns

Unclosed Resources

# BAD: File never closed

def read_file(path):

    f = open(path)

    return f.read()  # What if this raises?

Fix: Use context managers.

# GOOD

def read_file(path):

    with open(path) as f:

        return f.read()

Blocking in Async

# BAD: Blocks the entire event loop

async def fetch_data():

    time.sleep(1)  # Blocks everything!

    response = requests.get(url)  # Also blocks!

Fix: Use async-native libraries.

# GOOD

async def fetch_data():

    await asyncio.sleep(1)

    async with httpx.AsyncClient() as client:

        response = await client.get(url)

Type Safety Anti-Patterns

Missing Type Hints

# BAD: No types

def process(data):

    return data["value"] * 2

Fix: Annotate all public functions.

# GOOD

def process(data: dict[str, int]) -> int:

    return data["value"] * 2

Untyped Collections

# BAD: Generic list without type parameter

def get_users() -> list:

    ...

Fix: Use type parameters.

# GOOD

def get_users() -> list[User]:

    ...

Testing Anti-Patterns

Only Testing Happy Paths

# BAD: Only tests success case

def test_create_user():

    user = service.create_user(valid_data)

    assert user.id is not None

Fix: Test error conditions and edge cases.

# GOOD

def test_create_user_success():

    user = service.create_user(valid_data)

    assert user.id is not None

def test_create_user_invalid_email():

    with pytest.raises(ValueError, match="Invalid email"):

        service.create_user(invalid_email_data)

def test_create_user_duplicate_email():

    service.create_user(valid_data)

    with pytest.raises(ConflictError):

        service.create_user(valid_data)

Over-Mocking

# BAD: Mocking everything

def test_user_service():

    mock_repo = Mock()

    mock_cache = Mock()

    mock_logger = Mock()

    mock_metrics = Mock()

    # Test doesn't verify real behavior

Fix: Use integration tests for critical paths. Mock only external services.

Quick Review Checklist

Before finalizing code, verify:

• No scattered timeout/retry logic (centralized)

• No double retry (app + infrastructure)

• No hard-coded configuration or secrets

• No exposed internal types (ORM models, protobufs)

• No mixed I/O and business logic

• No bare except Exception: pass

• No ignored partial failures in batches

• No missing input validation

• No unclosed resources (using context managers)

• No blocking calls in async code

• All public functions have type hints

• Collections have type parameters

• Error paths are tested

• Edge cases are covered

Common Fixes Summary

Anti-Pattern

Fix

Scattered retry logic

Centralized decorators

Hard-coded config

Environment variables + pydantic-settings

Exposed ORM models

DTO/response schemas

Mixed I/O + logic

Repository pattern

Bare except

Catch specific exceptions

Batch stops on error

Return BatchResult with successes/failures

No validation

Validate at boundaries with Pydantic

Unclosed resources

Context managers

Blocking in async

Async-native libraries

Missing types

Type annotations on all public APIs

Only happy path tests

Test errors and edge cases