Skip to main content

Strategy Pattern in Python: Write Flexible, Clean Code

Strategy Pattern in Python: Write Flexible, Clean Code How to pick different algorithms at runtime—without a tangled web of if/else Hey there! Today I want to write about a design pattern:  the Strategy Pattern . Perfect for when you have multiple ways to solve the same problem and you want clean, maintainable code. Why the Strategy Pattern? Let’s start with a scenario: imagine you're building a pizza delivery app, and different restaurants have wildly different APIs. Without planning, you might end up stuffing your code full of branching logic. Instead, the Strategy Pattern lets you isolate each integration into its own “strategy,” making your code neat and flexible. In software design terms, a strategy defines a family of algorithms, each encapsulated in its own class (or callable), and they’re all interchangeable at runtime. This helps avoid massive if/else blocks and makes adding new behavior super easy without touching existing code—hell...
Post a Comment

Understanding the Python GIL (for Beginners)

What it is, why it matters, and what’s coming in future Python releases.

Hey! Let’s talk about something that trips up a lot of developers when they dive into Python threading: the Global Interpreter Lock, or GIL. We will cover the essentials here. This will be a good starting point to decide if you want or need to dig deeper in the topic.

What is the GIL?

The GIL is a lock inside CPython (the standard Python interpreter). It ensures only one thread executes Python bytecode at a time, even on multi-core machines. See more on Wikipedia and the Python Wiki.

It was put in place to manage Python’s internal systems (like memory and reference counting) without race conditions. Without the GIL, Python could crash or corrupt data. That’s why it exists, even if it feels limiting [1].

How does the GIL affect your code?

  • Single-threaded scripts: No change. The GIL is invisible.
  • I/O-bound tasks (like networking or file access): The GIL is released when waiting on I/O, so threads can switch smoothly [1].
  • CPU-bound tasks (heavy calculations): Threads won’t run in parallel. The GIL ensures only one runs at a time, even on multi-core CPUs [2].

Workarounds

  • Use multiprocessing: Separate processes have separate GILs, so your code can fully use multiple cores.
  • Use C extensions or libraries like NumPy: Heavy work happens outside Python bytecode, bypassing the GIL.
  • Consider asyncio: Great for I/O tasks without threading.

Here’s a quick example to show the difference:

import threading
import multiprocessing

def count(n):
    s = 0
    for i in range(n):
        s += i * i
    print("Done")

# Threaded: still runs one at a time
t1 = threading.Thread(target=count, args=(10**7,))
t2 = threading.Thread(target=count, args=(10**7,))
t1.start()
t2.start()
t1.join()
t2.join()

# Multiprocess: actually runs in parallel
p1 = multiprocessing.Process(target=count, args=(10**7,))
p2 = multiprocessing.Process(target=count, args=(10**7,))
p1.start()
p2.start()
p1.join()
p2.join()

This shows why multiprocessing beats threads for CPU-heavy tasks: each process has its own GIL.

The future: No more GIL?

Here’s the exciting part: Python 3.13 introduces an experimental no-GIL build via PEP 703. You can build CPython with --disable-gil to drop the GIL [3].

That means you could run Python threads truly in parallel on multi-core systems, just like in Java or C#. But it’s experimental. Many C extension modules will break or need rebuilding under the new memory and thread-safety rules [4].

Python 3.13 already supports a “free-threaded” build, typically called python3.13t. You can test it with: 

$ python3.13t -VV

or in Python:

import sys
print(sys._is_gil_enabled())  # check if GIL is active

Keep in mind it’s not yet the default. See the official “What’s New” notes for more details (Python 3.13 What’s New).

What this means for you

  • Today: Use threading for I/O tasks, and multiprocessing for CPU-heavy work.
  • Short term: Try the no-GIL build if you're curious, but don’t expect everything to work smoothly yet.
  • Long term: Python may eventually drop the GIL by default, but expect a multi-year, cautious rollout as libraries adapt.

TL;DR

The GIL stops Python threads from running true parallel bytecode. That’s fine for I/O, not great for CPU-bound tasks. Multiprocessing or native libraries are the current solutions. In the future, experimental no-GIL Python could let threads run in real parallel, but only once ecosystem catches up.

So next time you're tempted to use threading to speed things up, ask yourself: is it I/O or CPU bound? Plan accordingly, and maybe test the no-GIL build if you’re curious about what's ahead.

References

  1. “Understanding Python’s Global Interpreter Lock (GIL) Mechanism” – Dev.to — Explains why the GIL exists, how it works, and its impact on threaded Python.
  2. “What is the GIL in CPython?” – Stack Overflow — Community answer detailing how the GIL prevents true multi-core threading.
  3. "PEP 703: Making the Global Interpreter Lock Optional" — Official proposal explaining how to build CPython without the GIL (Python 3.13+).
  4. “Steering Council Notice on PEP 703” – Python Discussion Forum — Community discussion outlining potential module breakage and adoption concerns.
Labels:
Location: Germany

Comments

Post a Comment

Popular posts from this blog

Format Your Python Code with black (Using uv like a Pro)

Keep things clean, fast, and simple—no extra installs needed.   Hey there! I want to show you a smooth way to clean up your Python code using black , but with a twist: we’ll use uv to handle it. Why uv you might ask? My short answer: No cluttered virtual environments, no extra installs, just clean code. Why I Use uv (and you might too) If you’ve ever felt bogged down setting up virtual environments just to install tools like black , flake8 , or pytest , I hear you. uv is a package and project manager that’s fast, one-and-done, and smart (and written in Rust , by the way). It lets you run or install tools in clean, cache-friendly environments, with commands like: uv tool install black # keeps black handy on your PATH uvx black my_code.py # quick run in a temp environment Check out the uv docs, especially the "Tools" section, for all the details ( Astral Docs ). Step‑by‑Step: Get black Set Up 1. Install uv (from the  Astral Doc...
Post a Comment
Read more

Avoiding Pandas Pitfalls: View vs Copy and Keeping Your Base Dataframe Safe

Avoiding Pandas Pitfalls: View vs Copy and Keeping Your Base DataFrame Safe Ever accidentally changed your original pandas DataFrame without meaning to? I certainly have. It can feel like a debugging nightmare. In this post, I want to walk you through some of the lessons I’ve learned, like how pandas handles views and copies, and how to organize your code so you don't trip over unexpected behavior. Understanding View vs Copy in pandas In pandas, a “view” is just another way of looking at the same data in memory. That means if you change it, the original changes too. A “copy”, on the other hand, is a separate object entirely. What you do with it stays isolated. The problem is that pandas doesn’t always make it obvious whether you're dealing with a view or a copy. Sometimes a slice of a DataFrame gives you a view. Other times it gives you a copy. That inconsistency is the reason behind the infamous SettingWithCopyWarning [1] . For example, if...
Post a Comment
Read more