DEV Community: guzmanojero

A Tour of Python's Data Structures for Modeling Objects

guzmanojero — Thu, 09 Jul 2026 15:36:45 +0000

When people think about modeling data in Python, @dataclass is usually the first tool that comes to mind. And for good reason: it's concise, readable, and built into the standard library.

But Python offers several different ways to represent data, each designed for slightly different use cases.

In this article, we'll explore the most common approaches, compare their strengths and weaknesses, and discuss when you should choose one over another.

1. Regular Classes

Before Python 3.7, this was the standard way to model objects.

class Person:
    def __init__(self, name, age):
        self.name = name
        self.age = age

person = Person("Alice", 30)

Regular classes are extremely flexible.

You can define methods, properties, inheritance hierarchies, descriptors, custom constructors. Anything Python supports.

The downside is boilerplate. Even a simple data container requires writing an initializer and, if desired, __repr__, __eq__, ordering methods, and more.

Best when:

The object has significant behavior.
You need full control over object construction.
The class is more than just data.

2. Dataclasses

Introduced in Python 3.7, dataclasses automate much of the repetitive work involved in creating data-centric classes.

from dataclasses import dataclass

@dataclass
class Person:
    name: str
    age: int

This automatically generates:

__init__
__repr__
__eq__

And optionally:

ordering
hashing
immutability (frozen=True)
keyword-only fields
default factories
post-initialization hooks

The result is concise code that remains fully compatible with normal Python classes.

Best when:

Your class primarily stores data.
You still want methods and business logic.
You want readable, maintainable code.

For most modern Python projects, this is the default choice.

3. Dataclasses with slots=True

Python objects normally store their attributes in a dictionary (__dict__).

For large numbers of objects, that dictionary consumes additional memory.

Python 3.10 introduced a convenient way to combine dataclasses with __slots__.

from dataclasses import dataclass

@dataclass(slots=True)
class Person:
    name: str
    age: int

Benefits include:

lower memory usage
slightly faster attribute access
prevention of accidental new attributes

The trade-off is a small reduction in flexibility, since instances no longer have a normal __dict__.

Best when:

You create many instances.
The object's attributes are fixed.
Memory efficiency matters.

4. Classes with slots

Before slots=True was added to dataclasses, developers manually declared slots.

class Person:
    __slots__ = ("name", "age")

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

This produces many of the same performance characteristics as dataclass(slots=True).

However, it requires more manual work and can complicate inheritance.

Best when:

You're writing highly optimized classes.
You're not using dataclasses.

5. NamedTuple

Sometimes objects should never change after creation.

That's where NamedTupleshines.

from typing import NamedTuple

class Person(NamedTuple):
    name: str
    age: int

Instances are immutable.

person = Person("Alice", 30)

person.name
person[0]

Unlike dataclasses, NamedTuple behaves like both an object and a tuple.

This makes it lightweight, hashable, and efficient.

Best when:

Data should be immutable.
The object is essentially a record.
You want tuple compatibility.

6. collections.namedtuple

Before type annotations became common, Python provided collections.namedtuple.

from collections import namedtuple

Person = namedtuple("Person", ["name", "age"])

It offers many of the same runtime characteristics as NamedTuple.

The main differences are:

no class syntax
no type annotations
older API

For new projects, typing.NamedTuple is generally preferred.

7. TypedDict

Sometimes your data naturally belongs in a dictionary.

Instead of creating a custom object, you can describe the dictionary's expected structure.

from typing import TypedDict

class Person(TypedDict):
    name: str
    age: int

Usage:

person: Person = {
    "name": "Alice",
    "age": 30,
}

At runtime, this is still just a normal dictionary.

The type information exists primarily for static type checkers.

Best when:

You're working with JSON.
APIs already use dictionaries.
You don't need object methods.

8. SimpleNamespace

Sometimes you simply want attribute access without defining a class.

from types import SimpleNamespace

person = SimpleNamespace(
    name="Alice",
    age=30,
)

Now you can write person.name instead of person["name"].

Internally, SimpleNamespace stores everything in a regular __dict__.

It's lightweight, dynamic, and convenient for quick scripts.

Best when:

Rapid prototyping.
Small utilities.
Dynamic attributes.

9. Pydantic Models

Sometimes storing data isn't enough.

You also want validation, parsing, serialization, and automatic type conversion.

That's where Pydantic excels.

from pydantic import BaseModel

class Person(BaseModel):
    name: str
    age: int

Now this works:

person = Person(
    name="Alice",
    age="30",
)

print(person.age)
# 30

The string is automatically converted into an integer.

Pydantic also provides:

JSON serialization
schema generation
validation errors
nested models
parsing external data

It's one of the foundations of modern Python web development.

Best when:

Building APIs.
Reading configuration files.
Validating external input.
Working with typed JSON.

I hope that this article helped you.

Note: This article was written with the assistance of AI, primarily to verify syntax, grammar, formatting, and technical concepts.

A Complete Guide to Function Arguments in Python

guzmanojero — Thu, 02 Jul 2026 14:09:03 +0000

Every Way to Pass Arguments to a Function in Python

One of Python's strengths is the flexibility of its function signatures. Most developers learn positional and keyword arguments early on, but Python supports several other ways to define and pass arguments that make APIs more expressive and easier to evolve.

In this article, we'll cover every way arguments can be passed to a function in Python, from the basics to more advanced features like positional-only and keyword-only parameters.

1. Positional Arguments

The most common way to call a function is by passing arguments in the order the parameters are defined.

def greet(name, age):
    print(f"{name} is {age} years old.")

greet("Alice", 25)

Python matches arguments to parameters by their position.

2. Keyword Arguments

Instead of relying on order, you can specify the parameter names explicitly.

greet(age=25, name="Alice")

Since the names are provided, the order no longer matters.

This often makes function calls more readable, especially when there are several parameters.

3. Mixing Positional and Keyword Arguments

You can combine both styles in the same function call.

greet("Alice", age=25)

However, all positional arguments must come before keyword arguments.

✅ Valid:

greet("Alice", age=25)

❌ Invalid:

greet(name="Alice", 25)

This raises a SyntaxError.

4. Default Arguments

Parameters can define default values.

def connect(host, port=80):
    print(host, port)

Now both of these calls are valid:

connect("example.com")
connect("example.com", 443)

Default arguments help keep common function calls concise while still allowing customization when needed.

5. Variable Positional Arguments (`*args`)

Sometimes you don't know how many positional arguments will be passed.

*args collects them into a tuple.

def add(*numbers):
    print(numbers)
    return sum(numbers)

print(add(1, 2, 3, 4))

Inside the function:

numbers == (1, 2, 3, 4)

This is commonly used for functions that accept an arbitrary number of values.

6. Variable Keyword Arguments (`**kwargs`)

Similarly, **kwargs collects extra keyword arguments into a dictionary.

def create_user(**kwargs):
    print(kwargs)

create_user(name="Alice", age=25)

Output:

{
    "name": "Alice",
    "age": 25
}

This pattern is useful for flexible APIs or forwarding arguments to another function.

7. Unpacking Iterables with `*`

The * operator can also be used when calling a function.

Instead of collecting arguments, it expands an iterable into positional arguments.

values = ["Alice", 25]

greet(*values)

This is equivalent to:

greet("Alice", 25)

It works with lists, tuples, generators, and any iterable.

8. Unpacking Dictionaries with `**`

Likewise, ** expands a dictionary into keyword arguments.

person = {
    "name": "Alice",
    "age": 25,
}

greet(**person)

Equivalent to:

greet(name="Alice", age=25)

This is especially convenient when working with configuration dictionaries or serialized data.

9. Positional-Only Parameters (`/`)

Introduced in Python 3.8, the / marker allows you to define parameters that cannot be passed by keyword.

def divide(a, b, /):
    return a / b

Valid:

divide(10, 2)

Invalid:

divide(a=10, b=2)

This raises a TypeError.

Why would you use this?

Positional-only parameters let you change parameter names in future versions without breaking users' code, since callers never reference those names.

The Python standard library uses this technique extensively.

Understanding the `/` Separator

It's important to understand that the / does not separate positional arguments from keyword arguments. Instead, it classifies the parameters in the function definition.

Consider the following example:

def func(a, b, /, c, d):
    pass

The parameters are divided into two groups:

a and b are positional-only parameters. They can only receive arguments by position.
c and d are positional-or-keyword parameters. They can receive arguments either by position or by name.

For example, both of these calls are valid:

func(1, 2, 3, 4)

func(1, 2, c=3, d=4)

However, this is not:

func(a=1, b=2, c=3, d=4)
# TypeError

A common misconception is that every parameter after / must be passed by keyword. That's not the case, they can still be passed positionally unless a * later in the signature makes them keyword-only.

10. Keyword-Only Parameters (`*`)

The opposite is also possible.

Parameters after * must be passed by keyword.

def connect(host, *, timeout):
    print(host, timeout)

Valid:

connect("example.com", timeout=10)

Invalid:

connect("example.com", 10)

This raises a TypeError.

Keyword-only parameters improve readability and help prevent mistakes, particularly when a function has several optional arguments.

Putting It All Together

A single function can combine almost every parameter type.

def func(
    a,
    b,
    /,
    c,
    d=0,
    *args,
    e,
    f=10,
    **kwargs,
):
    print(f"a = {a}")
    print(f"b = {b}")
    print(f"c = {c}")
    print(f"d = {d}")
    print(f"args = {args}")
    print(f"e = {e}")
    print(f"f = {f}")
    print(f"kwargs = {kwargs}")

Example call:

func(
    1,
    2,
    3,
    4,
    5,
    6,
    e=7,
    f=8,
    color="red",
    size="large",
)

Output:

a = 1
b = 2
c = 3
d = 4
args = (5, 6)
e = 7
f = 8
kwargs = {'color': 'red', 'size': 'large'}

The Five Kinds of Parameters

Although we've discussed many ways to pass arguments, Python actually recognizes five kinds of parameters when defining a function.

Parameter Kind	Positional	Keyword
Positional-only	✅	❌
Positional-or-keyword	✅	✅
Variadic positional (`*args`)	Collects extras	❌
Keyword-only	❌	✅
Variadic keyword (`**kwargs`)	❌	Collects extras

Everything else, default values and argument unpacking, is built on top of these parameter kinds.

Summary

Method	Example	Description
Positional arguments	`f(1, 2)`	Matched by position.
Keyword arguments	`f(x=1, y=2)`	Matched by parameter name.
Mixed positional + keyword	`f(1, y=2)`	Positional first, keywords after.
Default arguments	`def f(x, y=0)`	Caller may omit the value.
Arbitrary positional (`*args`)	`def f(*args)`	Collects extra positional arguments into a tuple.
Arbitrary keyword (`**kwargs`)	`def f(**kwargs)`	Collects extra keyword arguments into a dictionary.
Iterable unpacking (`*`)	`f(*values)`	Expands an iterable into positional arguments.
Dictionary unpacking (`**`)	`f(**options)`	Expands a dictionary into keyword arguments.
Positional-only parameters (`/`)	`def f(x, /)`	Caller cannot use `x=`.
Keyword-only parameters (`*`)	`def f(*, x)`	Caller must use `x=`.

Final Thoughts

Python's function signature syntax is remarkably expressive. Whether you're designing a simple helper function or a public API, choosing the right parameter types can make your code:

More readable
Easier to maintain
Safer to evolve
Less error-prone

If you've only been using positional and keyword arguments, learning about positional-only and keyword-only parameters can significantly improve the clarity and stability of your APIs.

If you didn't know this, now you know it 💪💪💪

How to use match-case in Python (hint: not for if statements)

guzmanojero — Thu, 12 Feb 2026 16:29:11 +0000

match-case is Python’s structural pattern matching feature (introduced in Python 3.10).

Think of it as a much more powerful switch, designed to match not just values, but also shapes and structures of data.

Many people think that match-case is a fancy way for doing if statements. Well... you can, but its purpose goes beyond that.

1. Basic idea (value matching)

Yes, you can use it as a replacement for if statements. At its simplest, it looks like a switch statement in other languages:

def http_status_message(status):
    match status:
        case 200:
            return "OK"
        case 404:
            return "Not Found"
        case 500:
            return "Server Error"
        case _:
            return "Unknown status"

Key points:

match <expression>: evaluates once
Each case is tried top to bottom
_ is the wildcard (default case)

This is equivalent to using an if statement:

def http_status_message(status):
    if status == 200:
        return "OK"
    elif status == 404:
        return "Not Found"
    elif status == 500:
        return "Server Error"
    else:
        return "Unknown status"

But you don't gain too much here by using match.

I can even say that here you don't need an if statment either. Just use a dictionary when is data disguised as logic.

def http_status_message(status):
    messages = {
        200: "OK",
        404: "Not Found",
        500: "Server Error",
    }
    return messages.get(status, "Unknown status")

2. Structural pattern-matching (shapes and structures of data mataching)

It can destructure objects, check types, and bind variables.

Tuple / sequence matching

point = (0, 5)

match point:
    case (0, y):
        print(f"On Y axis at y={y}")
    case (x, 0):
        print(f"On X axis at x={x}")
    case (x, y):
        print(f"At ({x}, {y})")

What’s happening:

(0, y) means:

first element must be 0
second element is captured as y

This is not equality testing, you're not checking the value, you're checking the shape of the object.

3. Matching lists with rest (*)

numbers = [1, 2, 3, 4]

match numbers:
    case [first, *rest]:
        print(first, rest)

Rules:

*rest captures “the remaining elements”
Works only once per pattern

4. Type and class matching

You can match by type, and even unpack attributes.

Simple type matching.

def handle(value):
    match value:
        case int():
            print("Integer")
        case str():
            print("String")
        case list():
            print("List")

Class pattern matching

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

user = User("Alice", True)

match user:
    case User(name=name, is_admin=True):
        print(f"Admin: {name}")
    case User(name=name):
        print(f"User: {name}")

This checks:

instance of User
then matches attributes

5. Guards (`if` inside case)

Sometimes structure isn’t enough, sometimes you need conditions.

match value:
    case int(x) if x > 0:
        print("Positive integer")
    case int(x):
        print("Non-positive integer")

6. OR patterns (`|`)

match command:
    case "start" | "run" | "go":
        print("Starting…")
    case "stop" | "quit":
        print("Stopping…")

7. Dict (mapping) matching

data = {"type": "error", "code": 404}

match data:
    case {"type": "error", "code": code}:
        print(f"Error code {code}")

Notes:

Extra keys are allowed by default
Only listed keys must match

This is what you take after reading this blog post:

match-case asks: “Does this value have this shape?”
if asks: “Is this condition true?”

Extra reading:
https://www.pythonmorsels.com/switch-case-in-python

When to use getattr in Python

guzmanojero — Sun, 28 Dec 2025 18:56:29 +0000

At some point in Python, you realize that writing object.attribute isn’t always enough.

Sometimes:

The attribute name comes from user input
Sometimes it comes from configuration
Sometimes it comes from a loop
Sometimes you don’t even know which attribute you need until runtime

That’s where getattr comes in.

This post explains what getattr really does, what it doesn’t do, and when it actually makes sense to use it.

The basic idea

Normally, you access attributes like this:

p.name

That works only if you know the attribute name at coding time.

getattr lets you do the same thing, but dynamically:

getattr(p, "name")

If the string "name" matches an attribute on p, Python returns its value.

Are these the same?

Yes, but only in this specific case:

p.name
getattr(p, "name")

They both return the same value.

So why does getattr exist?

Because this is not possible with dot notation:

attr = "nombre"
p.attr        # looks for an attribute literally called "attr"

But this works:

attr = "name"
getattr(p, attr)

That’s the key difference.

Why “dynamic” matters

Let’s say you have a simple class:

class Person:
    def __init__(self):
        self.name = "Alice"
        self.age = 30

person = Person()

Now imagine the attribute you want depends on runtime logic:

fields = ["name", "age"]


for field in fields:
    print(getattr(person, field))

Without getattr, you’d be forced into using conditionals:

if field == "name":
    print(person.name)
elif field == "age":
    print(person.age)

Kind of ugly, isn't it?

Default values (avoiding crashes)

Another important feature: safe access.

If the attribute doesn’t exist, you get an AttributeError:

getattr(person, "height")

> AttributeError: 'Person' object has no attribute 'height'

But you can provide a fallback:

getattr(person, "height", 170)

Now your program continues safely.

Accessing methods dynamically

Attributes aren’t just data, methods are attributes too.

class Calculator:
    def add(self, x, y):
        return x + y

calc = Calculator()

method = getattr(calc, "add")
print(method(2, 3))  # 5

Isn't this cool?

What `getattr` does not do

getattr is not:

Faster than dot access
A replacement for normal attribute access
Something you should use everywhere

If you know the attribute name in advance, you may better chose the dot notation:

p.name

getattr is for flexibility, not style points.

Final thought

getattr isn’t about being clever.

It’s about writing code that adapts at runtime instead of being locked into hardcoded assumptions.

Once you see that, it becomes a very precise tool.

Write Cleaner Python with Guard Clauses

guzmanojero — Wed, 10 Dec 2025 17:15:06 +0000

One of the simplest techniques to make your functions easier to understand is the guard clause. It’s not a design pattern, not a framework feature, not Python‑specific—just a small structural decision that dramatically improves readability.

And yet, many developers either underuse it or don’t realize why it works so well.

Let’s explore it.

What Is a Guard Clause?

A guard clause is an early exit placed at the top of a function to immediately stop execution when the input or state is invalid.

Instead of wrapping your entire function logic inside multiple nested if blocks, you make the intention explicit:

“If this function can't continue, stop right here.”

This keeps the happy path flat and clear.

The Problem: Pyramid of Doom

Without guard clauses, you often end up with deep indentation and hard-to-follow branches.

def process(data):
    if data is not None:
        if isinstance(data, dict):
            if "value" in data:
                return data["value"] * 2
    return None

The function works, but reading it feels like descending a staircase. These nested conditions complicates the thinking of your code.

The Fix: Exit Early

Guard clauses flatten the structure.

def process(data):
    if data is None:
        return None
    if not isinstance(data, dict):
        return None
    if "value" not in data:
        return None

    return data["value"] * 2

This is much simplier. You have to think about one condition at a time.
You try to make it fail at the start. If it doesn't, the code continues.

Why Guard Clauses Improve Readability

They eliminate unnecessary nesting.
Every nested level makes logic harder to parse. Guard clauses remove that hierarchy.
They reveal invalid states immediately.
Readers don’t have to hunt through the body of the function to understand edge cases.
They keep the happy path obvious.
By removing noise, you highlight the core behavior of the function.
They reduce cognitive overhead.
No need to hold multiple active conditions in your mind.

Real Example: A Django View

Without guard clauses.

def dashboard(request):
    user = request.user

    if user.is_authenticated:
        if user.is_staff:
         return render(request, "dashboard.html")

    return redirect("login")

With guard clauses.

def dashboard(request):
    if not request.user.is_authenticated:
        return redirect("login")

    if not request.user.is_staff:
        return HttpResponseForbidden()

    return render(request, "dashboard.html")

Another Example: Business Logic

Without guard clauses.

def create_order(user, items):
    if user.is_active:
        if items:
            if user.credit >= sum(i.price for i in items):
                return "ok"

    return "error"

With guard clauses.

def create_order(user, items):
    if not user.is_active:
        return "error"
    if not items:
        return "error"
    if user.credit < sum(i.price for i in items):
        return "error"

    return "ok"

Flat. Readable. Calm.

A Subtle Benefit: Easier Refactoring

Guard clauses naturally push you toward smaller, cleaner functions.

Functions become:

shorter
more predictable
easier to test
safer to modify

If you find a function with many guard clauses, it’s often a hint that some logic can be split into smaller helpers.

When Not to Use Them

Guard clauses are great, but overuse can backfire.

Avoid them when:

the function has many unrelated early exits scattered everywhere
the code becomes harder to follow because the exits are too far apart

A few guard clauses at the top? Perfect.
Chaos in every branch? Not so much.

Final Thoughts

Guard clauses are a tiny technique with disproportionate impact. They make your code flatter, cleaner and more readable.

Next time you see nested if blocks forming a pyramid, try flipping the logic: reject invalid paths early and keep the main flow straight.

Your future self will thank you.

From Default to Custom: Handling Errors in Django Like a Pro

guzmanojero — Wed, 03 Dec 2025 18:56:30 +0000

Nobody likes the generic browser's error page — the kind that instantly breaks immersion and reminds users they’re looking at an unfinished feature. The good news? Django makes it surprisingly easy to replace those defaults with pages that feel polished and intentional.

This post walks through two practical methods:

Template-only overrides (drop in a file and you’re done)
Fully custom error handlers (your own views, logic, and folder structure)

1. Template‑Only Overrides (the quickest improvement)

Django has built‑in views for common HTTP errors:

404 — Page Not Found
500 — Server Error
403 — Permission Denied
400 — Bad Request

These views are located at: django.views.defaults

When these views run, they automatically try to load templates named exactly:

404.html
500.html
403.html
400.html

So if you create one of these files inside any folder Django can find, Django will render it instead of its plain default.

Example structure:

project_root/
└── templates/
└── 404.html
└── 500.html

No custom views. No URL changes. No special configuration.

You can repeat this for the other codes as well.

2. Fully Custom Error Handlers

If you want:

your own views,
your own folder like templates/errors/,
custom context,
or error‑specific logic,

…then you define custom error handlers.

Step 1: Create custom views

Let's create a folder called errors at project level. But you could put this anywhere.

# errors/views.py
from django.shortcuts import render


def error_404(request, exception):
return render(request, "errors/404.html", status=404)


def error_500(request):
return render(request, "errors/500.html", status=500)


def error_403(request, exception):
return render(request, "errors/403.html", status=403)


def error_400(request, exception):
return render(request, "errors/400.html", status=400)

These views will handle each custom error defined.

Step 2: Register the handlers in the project-level `urls.py`

# project/urls.py
from django.urls import path, include


urlpatterns = [
path("admin/", admin.site.urls),
path("", include("core.urls")),
]


handler404 = "errors.views.error_404"
handler500 = "errors.views.error_500"
handler403 = "errors.views.error_403"
handler400 = "errors.views.error_400"

These variable names (handler404, etc.) are mandatory. Django looks for them.

Step 3: Create your templates

I have set "DIRS": [BASE_DIR / "templates"], so Django will look for a templates folder at the project level.

templates/
└── errors/
├── 400.html
├── 403.html
├── 404.html
└── 500.html

Each template can extend your site layout and include consistent styling.

For example:

{% extends "base.html" %}

{% block content %}

<h1 class="mb-3">Upps... 404 error 🫨</h1>
<div>
    <h3>Sorry, what you're looking is not here</h3>
    <h4>Go <a href="{% url 'home' %}">home</a></h4>
</div>

{% endblock content %}

So this is it.
Now you're ready to handle storms.

Understanding All Ways to Reference the Django User Model

guzmanojero — Thu, 20 Nov 2025 16:49:22 +0000

When working with Django, the User model is central to authentication and user data management. But there’s more than one way to reference it, and choosing the wrong method can lead to subtle bugs, especially if you ever switch to a custom user model. In this post, I’ll break down all the ways to reference the User model, explain their differences, and when to use each.

1. Direct Import of the Default User

from django.contrib.auth.models import User

user = User.objects.get(pk=1)

This approach is straightforward and works fine if you’re only ever using Django’s built-in User. However, it will break if you later swap in a custom user model. For this reason, it’s generally not recommended in reusable or production code.

2. Using get_user_model()

Django provides a utility function to retrieve the currently active user model:

from django.contrib.auth import get_user_model

User = get_user_model()
user = User.objects.get(pk=1)

Returns: The actual user model class (default or custom).
Use case: Runtime operations like querying users, creating instances, or type-checking.
Pro tip: This is the recommended approach for runtime code in apps that might be reused with different user models.

3. Using settings.AUTH_USER_MODEL

When defining model relationships, the correct approach is to use a string reference to the user model:

from django.conf import settings
from django.db import models

class Profile(models.Model):
    user = models.OneToOneField(
             settings.AUTH_USER_MODEL,
             on_delete=models.CASCADE)

Returns: A string like "auth.User" or "users.CustomUser".
Use case: Model fields (ForeignKey, OneToOneField, ManyToManyField).
Benefit: Avoids circular import issues and works seamlessly with custom user models.

4. String Literal in Model Fields

You can also use a direct string literal:

class Article(models.Model):
    author = models.ForeignKey(
               'auth.User',
                on_delete=models.CASCADE)

Or, for a custom user model:

class Article(models.Model):
    author = models.ForeignKey(
               'users.CustomUser',
                on_delete=models.CASCADE)

Caution: Hardcoding auth.User makes your code less flexible if you later introduce a custom user model.

Understanding related_name in Django (With Clear Examples)

guzmanojero — Mon, 17 Nov 2025 19:34:54 +0000

When working with Django models, you’ll eventually need to link one model to another using a ForeignKey, OneToOneField, or ManyToManyField.

At that point, you’ll see an option called related_name.

What is it?

It’s used to give Django a reverse lookup name - the name you use to access all the related objects from the other side of the relationship.

Here’s the idea:

Whenever you define a relationship in Django, you automatically get two ways to access data:

Forward access → from the model that declares the field
Reverse access → from the other model back to this one

The related_name option controls that reverse access.

1. Without `related_name`

We have this example:

class Author(models.Model):
    name = models.CharField(max_length=100)

class Book(models.Model):
    title = models.CharField(max_length=100)
    author = models.ForeignKey(Author, on_delete=models.CASCADE)

If from book you want to get the author, you would do a forward access:
book.author.

But if you want to the get the book from the author, that is a reverse access: author.book_set.all()

Django auto-generates the name book_set.
Functional? Yes.
Pretty? No.

2. With `related_name`

Let’s give the reverse relation a meaningful name:

class Book(models.Model):
    title = models.CharField(max_length=100)
    author = models.ForeignKey(
        Author,
        on_delete=models.CASCADE,
        related_name="books", # New line
    )

Now the reverse lookup becomes: author.books.all().

3. When `related_name` Becomes Required

When a model has more than one ForeignKey, OneToOneField, or ManyToManyField pointing to the same other model, you must define related_name for at least one of these relationships.

This is because Django automatically generates a default related_name (e.g. book_set) for reverse access, and if multiple relationships point to the same model, these default names would clash.

4. Disabling the Reverse Relationship

If you don’t want a reverse lookup at all: related_name="+"

class Log(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE, related_name="+")

Final Takeaway

related_name gives you control over how you access related objects from the other side of a relationship.

Use it when:

You want a cleaner API (author.books.all() vs author.book_set.all())
You have multiple foreign keys to the same model
You want to disable reverse access entirely

It’s a small feature that makes your codebase far more readable.

What's the use of Intermediate models in Django (Many to Many Relationship)

guzmanojero — Sun, 16 Nov 2025 06:23:34 +0000

The Many-to-Many relationship is a cornerstone of database design, but what happens when you need to store extra data about that relationship? Standard Many-to-Many falls short.

In Django, the solution is the intermediary model or intermediary table.

Example 1: Enriching a Customer-Product Relationship

Let's start with a classic e-commerce scenario. A Customer can buy many Products, and a Product can be bought by many Customers. This is a Many-to-Many link.

If we only link Customer and Product, we can't capture vital transaction details like:

Quantity: How many units of the product were bought?
Date: When did the transaction occur?

This extra data doesn't belong to the Customer (it's not part of their intrinsic profile) or the Product (it changes with every sale). It belongs to the act of purchasing.

To capture this, we introduce a third model: Purchase. This model acts as the junction table, connecting Customer and Product while holding the relationship-specific data.

It holds:

product
customer
date purchased
quantity purchased

from django.db import models

class Product(models.Model):
    name = models.CharField(max_length=128)
    price = models.DecimalField(max_digits=5, decimal_places=2)

class Customer(models.Model):
    name = models.CharField(max_length=128)
    age = models.IntegerField()
    # Key change: Use the 'through' argument to specify the intermediary model
    products = models.ManyToManyField(Product, through='Purchase')

class Purchase(models.Model):
    # These two ForeignKey fields define the Many-to-Many relationship
    product = models.ForeignKey(Product, on_delete=models.CASCADE)
    customer = models.ForeignKey(Customer, on_delete=models.CASCADE)

    # These fields store the *data about the relationship*
    date = models.DateField()
    quantity = models.IntegerField()

When you buy a product, you do it through the Purchase model: the customer buys quantity of product in date.

The magic happens with the through='Purchase' argument on the ManyToManyField. It tells Django: "Don't create a default intermediary table for this relationship; use my custom Purchase model instead."

Something important to clarify.
The necessity for a third, connecting table is an inherent requirement of the Many-to-Many (M2M) relationship in databases, but Django handles this in two ways:

for simple M2M links (like Customer to Product) where no extra data is needed, Django automatically creates this intermediate table internally
if you need to store relationship-specific information, such as the quantity purchased in an Order, you must manually define this connecting table as a custom "through" model and use the through argument in your ManyToManyField, which requires you to manage the relationship by creating records in that explicit model instead of using the automatic methods.

As the Django documentation says:

...if you want to manually specify the intermediary table, you can use
the through option to specify the Django model that represents the
intermediate table that you want to use.

Example 2: Tracking Band Membership History

Let's now use the example from the Django Documentation.

You have a database of musicians with a Many-to-Many relationship to bands: a person (musician) can belong to many Groups (bands), and a Group has many Persons.

What data do you want to keep?

For musicians (person): name and instrument they play.
For the bands: name and style.

    from django.db import models

    class Person(models.Model):
        name = models.CharField(max_length=128)
        age  =  models.IntegerField() 


    class Group(models.Model):
        name   = models.CharField(max_length=128)
        style  = models.CharField(max_length=128)
        person = models.ForeignKey(Person, on_delete=models.CASCADE)

But, wouldn't you think that knowing when the person joined the band is important?

What model would be the natural place to add a date_joined field? It makes no sense to add it to Person or Group, because it's not an intrinsic field for each of them, but it's related to an action: joining the band.

So you make a small, but important adjustment. You create an intermediate model that will connect the Person and the Group with their Membership status (which includes the date_joined field).

The new version is like this:

from django.db import models
      
class Person(models.Model):
    name = models.CharField(max_length=128)
    age = models.IntegerField() 

class Group(models.Model):
    name = models.CharField(max_length=128)
    style = models.CharField(max_length=128)
    # Define the M2M relationship using the Membership model
    members = models.ManyToManyField(Person, through='Membership')

class Membership(models.Model):
    # Foreign Keys linking to the two main models
    person = models.ForeignKey(Person, on_delete=models.CASCADE)
    group = models.ForeignKey(Group, on_delete=models.CASCADE)

    # The crucial data about the relationship itself
    date_joined = models.DateField()

The changes are:

You added a new class called Membership which reflects the membership status.
In the Group model you added members = models.ManyToManyField(Person, through='Membership'). With this you relate Person and Group with Membership, thanks to through.

Example 3: students enrolling in courses.

The Students and Courses example is a classic demonstration of a many-to-many relationship, as a student can enroll in multiple courses, and a course can have multiple students.

You'll define the relationship by placing the ManyToManyField on one of the models. Let's use the Course model, but placing it on Student would work just as well.

from django.db import models

class Student(models.Model):
    name = models.CharField(max_length=100)
    student_id = models.CharField(max_length=10, unique=True)

class Course(models.Model):
    title = models.CharField(max_length=150)
    course_code = models.CharField(max_length=10, unique=True)

    # Define the M2M relationship here:
    # A Course can have many students, and a Student can be in many courses.
    students = models.ManyToManyField(Student)

But what if we want to store the date of enrollment?
Ahhaaa.... we have to use an intermediate model.

Ok, create a new model called Enrollment that explicitly links Student and Course and includes your new field, enrollment_date.

In models.py:

from django.db import models

class Student(models.Model):
    name = models.CharField(max_length=100)
    student_id = models.CharField(max_length=10, unique=True)

class Course(models.Model):
    title = models.CharField(max_length=150)
    course_code = models.CharField(max_length=10, unique=True)
    students = models.ManyToManyField(Student, through='Enrollment')

class Enrollment(models.Model):
    student = models.ForeignKey(Student, on_delete=models.CASCADE)    
    course = models.ForeignKey(Course, on_delete=models.CASCADE) 
    enrollment_date = models.DateField() 

    class Meta:
        # Ensures that the combination of student and course is unique
        unique_together = ('student', 'course')

If you didn't know about intermediate models, now you know 💪
I hope this article helped you.

Taking Screenshots in Selenium with Python

guzmanojero — Mon, 15 Sep 2025 15:06:07 +0000

Python Selenium gives you multiple ways to capture the entire page, specific HTML elements, or even raw screenshot data.

Let's start!

1. Visible Viewport Screenshot

The simplest approach is capturing what’s currently visible in the browser window.

from selenium import webdriver

driver = webdriver.Chrome()
driver.get("https://www.selenium.dev")

driver.save_screenshot("viewport.png")  # user-friendly alias
# or
driver.get_screenshot_as_file("viewport_file.png")  # same thing

driver.quit()

It captures only the visible viewport, not the full scrollable page.

Take into consideration that save_screenshot() is just a wrapper around get_screenshot_as_file(). Both return True on success, False on I/O errors.

2. Full-Page Screenshot

Capturing the entire page depends on the browser.

Firefox (native support):

from selenium import webdriver

driver = webdriver.Firefox()
driver.get("https://www.selenium.dev")

driver.get_full_page_screenshot_as_file("fullpage.png")

Chrome (using CDP):


import base64
from selenium import webdriver

driver = webdriver.Chrome()
driver.get("https://www.selenium.dev")

# Ask Chrome for layout metrics (get full content size)
metrics = driver.execute_cdp_cmd("Page.getLayoutMetrics", {})
width = int(metrics["contentSize"]["width"])
height = int(metrics["contentSize"]["height"])

# Override device metrics so Chrome renders the ENTIRE page
# in a single "virtual" viewport (width x height).
driver.execute_cdp_cmd(
    "Emulation.setDeviceMetricsOverride",
    {
        "mobile": False,  # emulate desktop, not mobile
        "width": width,  # full content width
        "height": height,  # full content height
        "deviceScaleFactor": 1,  # 1 = normal DPI (increase for HiDPI/retina)
    },
)

# Capture screenshot of this expanded surface
fullpage_screenshot = driver.execute_cdp_cmd(
    "Page.captureScreenshot", {"fromSurface": True}
)

# Clear the override to restore normal browser behavior 
driver.execute_cdp_cmd("Emulation.clearDeviceMetricsOverride", {})

# Save full page image to file
with open("screenshoot_fullpage_chrome.png", "wb") as f:
    f.write(base64.b64decode(fullpage_screenshot["data"]))

driver.quit()

As of the time of writing, Chrome does not natively support full-page screenshots, so the Chrome DevTools Protocol (CDP) method is necessary. This will change once the WebDriver BiDi protocol is completely implemented.

After setting a custom viewport with Emulation.setDeviceMetricsOverride, it’s a good practice to call Emulation.clearDeviceMetricsOverride once the screenshot is taken.

Technically, this step isn’t required if your script ends right after capturing the screenshot, since the browser session will close anyway. However, leaving the override active can affect later interactions: the page may render as if it were displayed on an abnormally large monitor, causing layout issues or unexpected JavaScript behavior.

Clearing the override restores Chrome to its normal viewport, ensuring consistent behavior if you plan to keep browsing, testing, or taking additional screenshots in the same session.

3. Screenshot of a Specific HTML Element

Sometimes you don’t need the whole page, just a particular element. Selenium makes this easy with WebElement.screenshot().

from selenium import webdriver
from selenium.webdriver.common.by import By

driver = webdriver.Chrome()
driver.get("https://www.python.org/")

element = driver.find_element(By.ID, "documentation")

# element.screenshot
element.screenshot(f"screenshot_webelement.png")

driver.quit()

Alternative: Get as PNG bytes

from selenium import webdriver
from selenium.webdriver.common.by import By

driver = webdriver.Chrome()
driver.get("https://www.python.org/")

element = driver.find_element(By.ID, "documentation")

# Gets the screenshot of the current element as a binary data.
png_bytes = element.screenshot_as_png
with open("screenshot_webelement_bytes.png", "wb") as f:
    f.write(png_bytes)

driver.quit()

Ok, we have reached the end of this article. I hope it helps 💪

Generating PDFs in Selenium with Python

guzmanojero — Sun, 14 Sep 2025 18:15:57 +0000

Introduction.

Printing web pages to PDF is a common task — whether for generating reports, saving invoices, or archiving pages. Selenium, combined with Python, makes this task simple and automatable. In this post, we’ll go through step by step how to generate PDF files of web pages using Selenium.

Prerequisites

Python 3.8+
Google Chrome
selenium package 4.0+

Step 1: Setting up Selenium with Chrome

from selenium import webdriver

driver = webdriver.Chrome()

Step 2: Navigate to the Page You Want to Print

driver.get("https://www.selenium.dev")

Step 3: Configure Print Options

Selenium provides a PrintOptions class to configure how the PDF should look.

from selenium.webdriver.common.print_page_options import PrintOptions

print_options = PrintOptions()
print_options.orientation = "portrait"  # or "landscape"
print_options.scale = 0.60               # Adjust scale
print_options.background = True         # Include background graphics

Step 4: Generate the PDF

When you call driver.print_page(), Selenium returns the PDF as a base64 string. We must decode it to bytes before saving it to a file.

Remember this:
A PDF is a binary file → a sequence of raw bytes (e.g., %PDF-1.7 followed by compressed streams).

If you try to write the base64 string directly to disk, you’ll just get a .txt file full of gibberish characters, not a valid PDF.

To go from the base64 text → real PDF, you must decode the base64 string into raw bytes:

import base64

pdf_base64 = driver.print_page(print_options=print_options)
pdf_bytes = base64.b64decode(pdf_base64)

Step 5: Save the PDF to Disk

with open("website_print_pdf", "wb") as f:
    f.write(pdf_bytes)

"wb" = write binary mode.
PDF is a binary file, so writing in text mode ("w") will break it.

Step 6: Close the Browser

Always clean up by quitting the driver:

driver.quit()

Complete Code

import base64
from selenium import webdriver
from selenium.webdriver.common.print_page_options import PrintOptions

# Setup Chrome
driver = webdriver.Chrome()

# Navigate to page
driver.get("https://www.selenium.dev")

# Configure print options
print_options = PrintOptions()
print_options.orientation = "portrait"
print_options.scale = 0.50
print_options.background = False

# Generate PDF
pdf_base64 = driver.print_page(print_options=print_options)
pdf_bytes = base64.b64decode(pdf_base64)

# Save PDF
with open("website_print.pdf", "wb") as f:
    f.write(pdf_bytes)

# Close browser
driver.quit()

Add this to your code and see what happens.
Comment here 💪


# Save PDF
with open("output_str.txt", "w") as f:
    f.write(pdf_base64)

with open("output_bytes.pdf", "wb") as f:
    f.write(pdf_bytes)

with open("output_bytes_in_txt.txt", "wb") as f:
    f.write(pdf_bytes)

What’s the Difference between sorted() vs .sort() in Python:

guzmanojero — Wed, 30 Jul 2025 13:28:28 +0000

If you've worked with lists in Python, you've probably come across both sorted() and .sort(). At first glance, they seem to do the same thing — sort data. But behind the scenes, they work quite differently.

Let’s break it down.

1) sorted() — Returns a New Sorted List

The sorted() in-built function can be used on any iterable: lists, tuples, dictionaries, etc. It doesn’t modify the original object. Instead, it returns a new sorted list.

# syntax:
sorted(iterable, key=None, reverse=False)

nums = [3, 1, 2]
sorted_nums = sorted(nums)

print(sorted_nums)  # [1, 2, 3]
print(nums)         # [3, 1, 2] — original list is unchanged

You can also sort in reverse or customize sorting with the key argument:

names = ['Alice', 'bob', 'Charlie']
print(sorted(names, key=str.lower))  # ['Alice', 'bob', 'Charlie']

2) .sort() — Sorts In-Place

The .sort() method is available only for lists. It modifies the list in place and returns None.

# syntax
list.sort(key=None, reverse=False)

nums = [3, 1, 2]
nums.sort()

print(nums)  # [1, 2, 3] — original list is changed

Just like sorted(), .sort() also supports key and reverse:

words = ['banana', 'Apple', 'cherry']
words.sort(key=str.lower)
print(words)  # ['Apple', 'banana', 'cherry']

3. Key Differences at a Glance

Feature	`sorted()`	`.sort()`
Type	Built-in function	List method
Return value	New sorted list	`None`
Original list	Unchanged	Modified (in-place)
Usable on	Any iterable	Lists only

Sorting Trivia

Historically, the sorting algorithm used was called Timsort but since Python 3.11 it was replaced by an improved algorithm called Powersort which is based in Timsort.

DEV Community: guzmanojero

A Tour of Python's Data Structures for Modeling Objects

1. Regular Classes

2. Dataclasses

3. Dataclasses with slots=True

4. Classes with slots

5. NamedTuple

6. collections.namedtuple

7. TypedDict

8. SimpleNamespace

9. Pydantic Models

A Complete Guide to Function Arguments in Python

Every Way to Pass Arguments to a Function in Python

1. Positional Arguments

2. Keyword Arguments

3. Mixing Positional and Keyword Arguments

4. Default Arguments

5. Variable Positional Arguments (*args)

6. Variable Keyword Arguments (**kwargs)

7. Unpacking Iterables with *

8. Unpacking Dictionaries with **

9. Positional-Only Parameters (/)

Why would you use this?

Understanding the / Separator

10. Keyword-Only Parameters (*)

Putting It All Together

The Five Kinds of Parameters

Summary

Final Thoughts

How to use match-case in Python (hint: not for if statements)

1. Basic idea (value matching)

2. Structural pattern-matching (shapes and structures of data mataching)

3. Matching lists with rest (*)

4. Type and class matching

5. Guards (if inside case)

6. OR patterns (|)

7. Dict (mapping) matching

When to use getattr in Python

The basic idea

Are these the same?

Why “dynamic” matters

Default values (avoiding crashes)

Accessing methods dynamically

What getattr does not do

Final thought

Write Cleaner Python with Guard Clauses

What Is a Guard Clause?

The Problem: Pyramid of Doom

The Fix: Exit Early

Why Guard Clauses Improve Readability

Real Example: A Django View

Another Example: Business Logic

A Subtle Benefit: Easier Refactoring

When Not to Use Them

Final Thoughts

From Default to Custom: Handling Errors in Django Like a Pro

1. Template‑Only Overrides (the quickest improvement)

2. Fully Custom Error Handlers

Step 1: Create custom views

Step 2: Register the handlers in the project-level urls.py

Step 3: Create your templates

Understanding All Ways to Reference the Django User Model

1. Direct Import of the Default User

2. Using get_user_model()

3. Using settings.AUTH_USER_MODEL

4. String Literal in Model Fields

Understanding related_name in Django (With Clear Examples)

1. Without related_name

2. With related_name

3. When related_name Becomes Required

4. Disabling the Reverse Relationship

Final Takeaway

What's the use of Intermediate models in Django (Many to Many Relationship)

Example 1: Enriching a Customer-Product Relationship

Example 2: Tracking Band Membership History

Example 3: students enrolling in courses.

Taking Screenshots in Selenium with Python

1. Visible Viewport Screenshot

2. Full-Page Screenshot

Firefox (native support):

5. Variable Positional Arguments (`*args`)

6. Variable Keyword Arguments (`**kwargs`)

7. Unpacking Iterables with `*`

8. Unpacking Dictionaries with `**`

9. Positional-Only Parameters (`/`)

Understanding the `/` Separator

10. Keyword-Only Parameters (`*`)

5. Guards (`if` inside case)

6. OR patterns (`|`)

What `getattr` does not do

Step 2: Register the handlers in the project-level `urls.py`

1. Without `related_name`

2. With `related_name`

3. When `related_name` Becomes Required