Forem: guzmanojero

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.

How to Add Markdown in Django — The Safe Way

guzmanojero — Sun, 25 May 2025 06:29:08 +0000

Using Markdown in your blog is awesome — until it opens up a security hole you didn’t expect.

In this post, I’ll show how I fixed a potential XSS vulnerability in my Django app after adding Markdown support and using the safe filter in my templates.

I’ll cover:

How to add Markdown in your templates
Why using the safe template filter can be risky
How I sanitize Markdown-rendered HTML with nh3
Where to apply sanitization: forms, models, filter?
A reusable sanitize_html() helper for clean and safe input

Let's first see the relevant parts of this project.

We have a Post model.

# models.py
class Post(models.Model):
    title = models.CharField()
    title_tag = models.CharField()
    body = models.TextField()
    user = models.ForeignKey(User, on_delete=models.CASCADE)

We have a Form model:

# forms.py
class PostForm(ModelForm):
    class Meta:
        model = Post
        fields = "__all__"

And this is the (simplified) template:

<div> {{ post.body }} </div>

What is the idea?

To allow the user to use Markdown when using the form.

First step: add markdown

We will use the markdown library.

Install it:

pip install markdown

We have to create a new folder called templatetags inside the app folder.

Inside we will create a file where we are going to register a custom filter to safely allow Markdown rendering in a specific HTML element. I'll use markdown_extras.py.

your_app/
├── templatetags/
│   └── markdown_extras.py
├── ...

# markdown_extras.py

import markdown

from django import template
from django.template.defaultfilters import stringfilter

register = template.Library()


@register.filter
@stringfilter
def convert_markdown(value):
    md = markdown.markdown(
        value,
        extensions=["markdown.extensions.fenced_code", 
                    "markdown.extensions.tables"],
    )

    return md

This code defines a custom Django template filter called convert_markdown, which takes a string written in Markdown and converts it into HTML. The markdown.markdown() method does the actual conversion.

stringfilter converts an object to its string value before being passed to your function. If you’re writing a template filter that only expects a string as the first argument, you should use the decorator stringfilter.

It ensures the filter only processes string values, avoiding potential errors if the input is None or a non-string type.

The fenced_code blocks extension adds a secondary way to define code blocks, which overcomes a few limitations of indented code blocks.

And the tables extension adds the ability to create tables in Markdown documents.

This allows users to write code blocks using triple backticks and have them rendered correctly as <pre><code> blocks in HTML.

Import your custom template filter.

At the top of the template where you want to render Markdown write {% load markdown_extras %}.

This line is used in your Django template to import your custom template filter.

When you create a custom filter in a file like markdown_extras.py you must explicitly load that file in any template where you want to use its filters.

Apply the filter in the html element

We want post.body to render Markdown:

{% load markdown_extras %}

<div> {{ post.body|convert_markdown }} </div>

We are almost there... we need one more step for rendering Markdown.

Apply the safe filter.

{% load markdown_extras %}

<div> {{ post.body|convert_markdown|safe }} </div>

We are telling Django not to escape the HTML that was generated by the convert_markdown filter.

By default, Django escapes all variables in templates to protect against XSS (Cross-Site Scripting) attacks. This means if your Markdown input contains <strong>bold</strong> or <code>, Django would show them as plain text instead of rendering them as HTML. But with safe Django won't escape the HTML.

Voilá... you can render Markdown now.

Test it with:

### This is a Header
_This is in italic_

But because Django is not escaping HTML because of the use of the safe filter you can also do this:

<script> alert("Upps... unsafe code here!") </script>

Ohhh... you now have an unsafe web that is prone to attacks.

Second step: sanitation

Sanitizing HTML means cleaning user-generated HTML content to remove any potentially dangerous code — especially scripts or malicious tags — before displaying it on a website.

When users submit content (like blog posts, comments, or Markdown), they could try to inject harmful HTML or JavaScript like this:

<script src="https://example.com/evil.js"></script>

I'll use the nh3 library for sanitation.

Install it:

pip install nh3

Use clean() to sanitize HTML fragments.

We have one question to answer now: where are we going to perform the sanitation?

There are three common places:

In the forms
In the models
In the filter

In the forms.

As we applied the safe filter in the body, the sanitation will be applied in the body as well. We have to add a clean_body method in PostForm.


import nh3
from django.forms import ModelForm

# forms.py
class PostForm(ModelForm):
    class Meta:
        model = Post
        fields = "__all__"

    def clean_body(self):
        return nh3.clean(
            html=self.cleaned_data["body"],
            tags={"p", "b", "i", "u", "em", "strong",
                "ul", "ol", "li", "a", "table", "thead",
                "tbody", "tr", "th", "td", "blockquote",
            },
        )

This method returns a cleaned html.

It basically receives the html to be sanitized as first parameter and a whitelist of allowed HTML tags. You can check all parameters here.

Why would you sanitize in the form?

🔶Pros:

Early validation: The data is sanitized before it’s saved to the database, allowing you to catch and report disallowed content to the user immediately during form submission.
Keeps the database safe: Prevents malicious HTML from ever being stored.
Works well with user input: Forms are the primary place where users submit HTML.

🔶Cons:

Can be bypassed if data is inserted directly into the model — for example, through the Django admin, an API endpoint, or scripts run via the terminal or in a view (e.g. Post.objects.create(...))

🔶 When to use it:
Ideal for user-facing forms. You control 100% of your write paths and they all go through Django forms.

It’s a great balance between security and usability.

In the model.

If you want to be sure there is no bypassing you can sanitize directly in the model.


import nh3

from django.db import models

class Post(models.Model):
    title = models.CharField()
    title_tag = models.CharField()
    body = models.TextField()
    user = models.ForeignKey(User, on_delete=models.CASCADE)

    def save(self, *args, **kwargs):
        self.body = nh3.clean(
            self.body,
            tags={"p", "b", "i", "u", "em", "strong",
                "ul", "ol", "li", "a", "table", "thead",
                "tbody", "tr", "th", "td", "blockquote",
            },
        )
        super().save(*args, **kwargs)

You're making sure that when you save the model all the HTML will be cleaned.

You override the save() method. This ensures sanitization always happens, no matter where save() is called — from forms, views, admin, API, shell, etc.

Why would you sanitize in the model?

🔶Pros:

Catches everything: Ensures that all data saved to the model (no matter the source) is sanitized.
Centralized protection: No matter how the data enters the model, it’s cleaned.

🔶Cons:

Not as readable or obvious
Adds logic to your model that might be better kept elsewhere.
Harder to unit test in isolation.

🔶When to use it:
If data comes from multiple sources (not just forms), or if you're building a security-critical app.

In the filter.

Remember the convert_markdown template filter we created earlier?
When you're converting Markdown to HTML you can clean the HTML.


import markdown
import nh3

from django import template
from django.template.defaultfilters import stringfilter

@register.filter
@stringfilter
def convert_markdown(value):
    html = markdown.markdown(
        value,
        extensions=["markdown.extensions.fenced_code", 
                    "markdown.extensions.tables"],
    )
    clean_html = nh3.clean(
            html,
            tags={"p", "b", "i", "u", "em", "strong",
                "ul", "ol", "li", "a", "table", "thead",
                "tbody", "tr", "th", "td", "blockquote",
            },
    )
    return clean_html

By now I guess you already grasp the idea of what is this function doing.
No matter what is saved in the database or introduced in the form, the HTML will always be sanitized when rendering.

Why would you sanitize in the template filter?

🔶Pros:

Gives full control over rendering: You only sanitize right before displaying.
Allows raw HTML in the DB: You can reprocess it differently in the future (e.g. export to PDF).

🔶Cons:

Risky if someone forgets to apply the filter: Dangerous content may be displayed.
Leaves dangerous HTML in your database, which may leak if you export it.

🔶When to use it:
Only when you need to store rich content exactly as submitted, but want to control how it’s rendered in views/templates.

As a summary:

Where	Pro	Con	Use When...
Forms	Keeps DB safe early	May miss Admin/shell inserts	Users submit HTML through forms
Models	Catches all data sources	Can clutter model logic	Data comes from multiple sources
Filters	Flexible rendering	Dangerous if someone forgets to filter	You want to store raw HTML + control output

And, of course, you can combine approaches if needed.

If you're going to sanitize in many places you may apply some DRY concepts and abstract a little bit.

Instead of repeating nh3.clean() everywhere, we will create an utils function that will take care of the sanitization.

At the root level create a folder named utils, inside create a file named sanitization.py.


# utils/sanitization.py

import nh3

SAFE_TAGS = {"p", "strong", "em", "ul", "ol", "li", "a",
             "u", "h1", "h2", "h3", "table", "thead", "tbody",
             "tr", "th", "td", "pre", "code", "blockquote", "span",
}

SAFE_ATTRIBUTES = {
    "a": {"href", "title"},
    "span": {"style"},
}


def sanitize_html(html: str) -> str:
    return nh3.clean(
        html,
        tags=SAFE_TAGS,
        attributes=SAFE_ATTRIBUTES,
    )

And now we change all the places where we did sanitization:


# <app_name>/forms.py

import utils.sanitization as sanitization

def clean_body(self):
        html = self.cleaned_data["body"]
        html_cleaned = sanitization.sanitize_html(html)
        return html_cleaned


# <app_name>/models.py

import utils.sanitization as sanitization

def save(self, *args, **kwargs):
        self.body = sanitization.sanitize_html(self.body)
        super().save(*args, **kwargs)


# templatetags/markdown_extras.py

import utils.sanitization as sanitization

@register.filter
@stringfilter
def convert_markdown(value):
    html = markdown.markdown(
        value,
        extensions=["markdown.extensions.fenced_code", 
                    "markdown.extensions.tables"],
    )
    clean_html = sanitization.sanitize_html(html)
    return clean_html

Wrapping Up

Allowing users to write Markdown in your Django app makes content creation a breeze — but it also opens the door to potentially dangerous HTML if you're not careful. The safe filter tells Django to trust the output, so it's your job to ensure that what you're marking as "safe" is actually sanitized.

By using a library like nh3 to clean the rendered HTML, you can keep your app both functional and secure.

Markdown + Sanitization = Clean formatting without the XSS headaches.

Happy coding — and stay safe!

Further reading: https://adamj.eu/tech/2023/12/13/django-sanitize-incoming-html-nh3/

How to Customize Widgets in Django Forms

guzmanojero — Mon, 14 Apr 2025 22:45:44 +0000

When working with Django forms, one of the first things you'll want to do is customize how your form fields look and behave. Whether it's adding CSS classes, placeholders, or changing the type of input, Django gives you multiple ways to tweak widgets.

In this article, we'll walk through how to customize widgets in two scenarios:

A plain vanilla form (based on forms.Form)
A model form (based on forms.ModelForm)

Let’s dive in. 🏊‍♂️

1. Customizing Widgets in Vanilla Forms (`forms.Form`)

We have this contact form.

from django import forms

class ContactForm(forms.Form):
    subject = forms.CharField(max_length=100)
    message = forms.CharField(widget=forms.Textarea)
    sender = forms.EmailField()
    cc_myself = forms.BooleanField()

Options:

Option 1: define the Widget Inline. You set the widget right inside the field definition.
Option 2: modify a widget in the form definition.
Option 3: modify Widgets in __init__. If you need conditional logic (based on a user or some external flag), you can update the widget after instantiation.

Let's see all options in one form example:

# forms.py

class ContactForm(forms.Form):
    subject = forms.CharField(
        max_length=100,
        # *** CUSTOMIZE WIDGET: option 1 ***
        widget=forms.TextInput(
            attrs={
                "class": "form-control",
                "placeholder": "Subject",
            }
        ),
    )
    message = forms.CharField(widget=forms.Textarea)
    sender = forms.EmailField()
    cc_myself = forms.BooleanField(required=False)

    # *** CUSTOMIZE WIDGET: option 2 ***
    message.widget.attrs.update(
        {"class": "form-control", "placeholder": "Write your message here"}
    )

    # *** CUSTOMIZE WIDGET: option 3 ***
    def __init__(self, *args, user=None, **kwargs):
        super().__init__(*args, **kwargs)
        self.fields["sender"].widget.attrs["class"] = "form-control"

        # Conditional logic based on user
        if user and user.is_authenticated:
            self.fields["sender"].initial = user.email
        else:
            print(user)
            self.fields["sender"].widget.attrs["readonly"] = True
            self.fields["sender"].widget.attrs[
                "placeholder"
            ] = "Login to fill your email"

The user is passed into the view when instantiating the form:

#views.py

def form3(request):
    if request.method == "POST":
        form = ContactForm(request.POST)
        if form.is_valid():
            context = {"form": form}
            messages.success(request, "Your message has been sent!")
            return redirect("form")
    else:
        form = ContactForm(user=request.user)
    context = {"form": form}
    return render(request, "form.html", context=context)

2. Customizing Widgets in Model Forms (`forms.ModelForm`)

We have this form and model.


#forms.py
class PostForm(ModelForm):
    class Meta:
        model = Post
        fields = "__all__"


# models.py
class Post(models.Model):
    title = models.CharField()
    title_tag = models.CharField()
    body = models.TextField()
    user = models.ForeignKey(User, on_delete=models.CASCADE)

You can customize the widget like this:

Options:

Option 1: override fields manually
Option 2: use widgets inside the Meta class
Option 3: modify Widgets in __init__. If you need conditional logic (based on a user or some external flag), you can update the widget after instantiation.

Let's see all options in one form example:


class PostForm(ModelForm):
    # *** CUSTOMIZE WIDGET: option 1 ***
    title = forms.CharField(
        widget=forms.TextInput(
            attrs={"class": "form-control", "placeholder": "Here goes the title"}
        )
    )

    class Meta:
        model = Post
        fields = "__all__"
        # *** CUSTOMIZE WIDGET: option 2 ***
        widgets = {
            "body": forms.Textarea(attrs={"class": "form-control", "rows": 5}),
        }

    # *** CUSTOMIZE WIDGET: option 3 ***
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.fields["title_tag"].widget.attrs.update(
            {"class": "form-control", "placeholder": "Title tag"}
        )

Now you are free to customize the widgets in your project!

Forem: guzmanojero

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):

Chrome (using CDP):

3. Screenshot of a Specific HTML Element

Generating PDFs in Selenium with Python

Introduction.

Prerequisites

Step 1: Setting up Selenium with Chrome

Step 2: Navigate to the Page You Want to Print

Step 3: Configure Print Options

Step 4: Generate the PDF

Step 5: Save the PDF to Disk

Step 6: Close the Browser

Complete Code

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

1) sorted() — Returns a New Sorted List

2) .sort() — Sorts In-Place

3. Key Differences at a Glance

Sorting Trivia

How to Add Markdown in Django — The Safe Way

What is the idea?

First step: add markdown

Second step: sanitation

In the forms.

In the model.

In the filter.

Wrapping Up

How to Customize Widgets in Django Forms

1. Customizing Widgets in Vanilla Forms (forms.Form)

Options:

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

1. Customizing Widgets in Vanilla Forms (`forms.Form`)

2. Customizing Widgets in Model Forms (`forms.ModelForm`)