DEV Community: Pradeep Kumar

Testing with pytest: Fixtures, Fake Models, and Properties

Pradeep Kumar — Sat, 24 Oct 2026 08:22:41 +0000

Here's a feeling you'll know soon enough. You change one small thing in your code, and you're not sure what else you just broke. So you run the program by hand, try a couple of inputs, and hope.

Tests replace the hoping. A test is a small piece of code that checks another piece of code, and you can run hundreds of them in a second. This post is core, and it matters even more for AI work than for ordinary programming, because AI apps have a part that's unpredictable (the model) surrounded by a lot of code that isn't. That surrounding code is what we'll test.

Tests are not evals

Before we start, one distinction that will save you confusion later.

Tests check your code. Given this input, does the function return that output? They're fast, free, and always give the same answer.
Evals measure how good the model's answers are. They call a real model, the results vary, and they take real time and money. That's Post 60.

You need both. This post is about the first kind. And the trick for testing code that talks to a model is to replace the model with a fake, which is the heart of this post.

Your first test

We'll use the textkit package from Post 12. Install pytest in your project's environment:

pip install pytest

If you set up the dev extras in Post 12, pip install -e ".[dev]" does it for you. With uv, it's uv add --dev pytest.

Create a file called tests/test_counting.py:

from textkit.counting import count_words, top_words

def test_counts_repeated_words():
    assert count_words("the cat the dog") == {"the": 2, "cat": 1, "dog": 1}

def test_ignores_case_and_punctuation():
    assert count_words("The cat. the CAT,") == {"the": 2, "cat": 2}

def test_top_words_returns_at_most_n():
    result = top_words("a b c d e f", n=3)
    assert len(result) == 3

def test_top_words_orders_by_count():
    result = top_words("x y y z z z", n=2)
    assert result == [("z", 3), ("y", 2)]

Now run:

pytest

You'll see something like this (your version numbers and timing will differ):

============================= test session starts ==============================
collected 4 items

tests/test_counting.py ....                                              [100%]

============================== 4 passed in 0.02s ===============================

Each dot is a passing test. That's the whole system. Two rules make pytest find your tests:

Files are named test_something.py.
Test functions are named test_something.

And a test is just a function with a plain assert in it. If the assert is true, the test passes. If it's false, the test fails.

When a test fails

Say we break a test on purpose by changing the expected length to 4. Here's the kind of message pytest gives you:

def test_top_words_returns_at_most_n():
        result = top_words("a b c d e f", n=3)
>       assert len(result) == 4
E       assert 3 == 4
E        +  where 3 = len([('a', 1), ('b', 1), ('c', 1)])

tests/test_counting.py:14: AssertionError

Notice it doesn't just say "failed." It shows the line, the values on both sides, and where the number came from. That's a big part of why people like pytest. You rarely need extra print statements to understand a failure.

One practical note. The tests import textkit, which works because you installed the package in editable mode in Post 12. If you'd rather not, you can add this to pyproject.toml so pytest finds your code in src/:

[tool.pytest.ini_options]
testpaths = ["tests"]
pythonpath = ["src"]

What makes a good test

A few habits, learned the hard way by lots of programmers:

One idea per test. If a test fails, the name should tell you what broke. test_ignores_case_and_punctuation is much better than test_stuff.
Arrange, act, assert. Set things up, do the thing, check the result. Keeping those three steps visible makes tests easy to read.
Test behavior, not insides. Check what a function returns or does, not how it does it. Then you can rewrite the inside and the tests still pass.
Cover the edges. Empty input, a single item, very long input, odd characters, zero, negative numbers. Bugs hide at the edges.
Keep them fast and independent. A test shouldn't rely on another test running first.

Every time you find a bug, write a test that fails because of it, then fix the bug. It's the "lock it in" step from Post 11, and it means the same bug can never sneak back unnoticed.

Testing that an error is raised

Sometimes the correct behavior is to fail. Remember set_temperature from Post 11? Here's how you check it raises an error:

import pytest

def set_temperature(value):
    if not 0 <= value <= 2:
        raise ValueError("temperature must be between 0 and 2")
    return value

def test_temperature_rejects_out_of_range():
    with pytest.raises(ValueError, match="temperature"):
        set_temperature(5)

pytest.raises is a context manager (Post 8). The test passes only if the code inside the with block raises that error. The optional match checks the message too. If no error happens, the test fails.

Many cases, one test: parametrize

You often want to run the same check on lots of inputs. Instead of copying the test, use a decorator with arguments (Post 8 again):

import pytest

from textkit.counting import count_words

@pytest.mark.parametrize(
    "text, expected",
    [
        ("", {}),
        ("hello", {"hello": 1}),
        ("A a", {"a": 2}),
    ],
)
def test_count_words_edge_cases(text, expected):
    assert count_words(text) == expected

Pytest runs this function three times, once per row, and reports each one separately. Adding a new case is one new line.

Fixtures: reusable setup

A lot of tests need the same starting point: a file to read, a configured object, a fake service. A fixture is a function that builds that thing, and pytest hands it to any test that asks for it by name.

Remember the text pipeline from Post 7? To test it, we need a file. Pytest has a built-in fixture called tmp_path that gives you a fresh temporary folder, and we can build our own fixture on top of it:

import pytest

from pipeline import keep_real_text, read_lines

@pytest.fixture
def temp_notes(tmp_path):
    path = tmp_path / "notes.txt"
    path.write_text("line one is long enough to keep\nshort\n")
    return path

def test_pipeline_keeps_only_long_lines(temp_notes):
    lines = list(keep_real_text(read_lines(temp_notes)))
    assert lines == ["line one is long enough to keep"]

See how it works. The test has a parameter called temp_notes. Pytest notices that name, finds the fixture with the same name, runs it, and passes in the result. Each test gets a fresh one, and the temporary folder is cleaned up afterward.

(One heads-up. If your pipeline.py from Post 7 has code at the bottom that runs the pipeline, importing it in a test will run that code too. That's exactly what the if __name__ == "__main__": guard from Post 12 is for. Wrap the bottom part in it.)

If several test files need the same fixture, put it in a file called conftest.py in the tests/ folder. Pytest picks it up automatically, with no import needed.

monkeypatch: changing things temporarily

Another built-in fixture, monkeypatch, lets a test change something and automatically puts it back afterward. It's perfect for environment variables, like the API key from Post 12:

import os

import pytest

def get_api_key():
    key = os.environ.get("MODEL_API_KEY")
    if key is None:
        raise RuntimeError("Set the MODEL_API_KEY environment variable first")
    return key

def test_missing_key_raises(monkeypatch):
    monkeypatch.delenv("MODEL_API_KEY", raising=False)
    with pytest.raises(RuntimeError):
        get_api_key()

def test_key_is_read(monkeypatch):
    monkeypatch.setenv("MODEL_API_KEY", "test-key")
    assert get_api_key() == "test-key"

Both tests work no matter what's set on your computer, and neither leaves a mess behind.

Testing code that calls a model

Now the part you came for. Suppose you have a function that asks a model for JSON and retries if the reply isn't valid. Testing it against a real model would be slow, cost money, need an API key, and give a different answer each time. You can't test logic that way.

The fix is to make the model something you can swap out, which is exactly what we set up in Post 9 with composition and protocols. Here's the function (add it as src/textkit/replies.py):

import json

def get_json_reply(model, prompt, max_attempts=3):
    """Ask the model for JSON. Retry if the reply isn't valid JSON."""
    for _ in range(max_attempts):
        reply = model.generate(prompt)
        try:
            return json.loads(reply)
        except json.JSONDecodeError:
            prompt = prompt + "\nYour last reply was not valid JSON. Reply with JSON only."
    raise ValueError("Model never returned valid JSON")

It takes model as a parameter, and all it needs is something with a generate method. So in tests, we hand it a fake: a tiny class that returns replies we chose in advance.

class FakeModel:
    """A stand-in for a real model that returns canned replies."""

    def __init__(self, replies):
        self.replies = list(replies)
        self.calls = []

    def generate(self, prompt):
        self.calls.append(prompt)
        return self.replies.pop(0)

It also records every prompt it received in self.calls, so tests can check what we sent. Now the tests:

import pytest

from textkit.replies import get_json_reply

def test_returns_parsed_json():
    model = FakeModel(['{"answer": 42}'])
    assert get_json_reply(model, "Give me JSON") == {"answer": 42}

def test_retries_after_bad_json():
    model = FakeModel(["not json", '{"answer": 42}'])

    result = get_json_reply(model, "Give me JSON")

    assert result == {"answer": 42}
    assert len(model.calls) == 2
    assert "not valid JSON" in model.calls[1]

def test_gives_up_after_max_attempts():
    model = FakeModel(["bad", "bad", "bad"])
    with pytest.raises(ValueError, match="valid JSON"):
        get_json_reply(model, "Give me JSON")

These tests run instantly, cost nothing, and are the same every time. And they check real things: that good JSON is parsed, that a bad reply triggers a retry, that the retry prompt includes the correction message, and that we give up eventually instead of looping forever.

When you can't pass a fake in: mock and patch

Sometimes the model call is buried inside code you can't easily change. Python's built-in unittest.mock library has tools for that, and they work fine inside pytest.

Mock makes an object that accepts any call and remembers it:

from unittest.mock import Mock

def test_works_with_a_mock_object():
    model = Mock()
    model.generate.return_value = '{"answer": 1}'

    assert get_json_reply(model, "x") == {"answer": 1}
    model.generate.assert_called_once_with("x")

side_effect lets a mock fail or change its answer from call to call. This is great for testing retries without waiting around:

def call_with_retries(func, attempts=3):
    for attempt in range(1, attempts + 1):
        try:
            return func()
        except TimeoutError:
            if attempt == attempts:
                raise

def test_retries_then_succeeds():
    flaky = Mock(side_effect=[TimeoutError("slow"), "ok"])
    assert call_with_retries(flaky) == "ok"
    assert flaky.call_count == 2

patch temporarily replaces a real function by name. Imagine my_app.py has a function call_api that hits the network, and answer that uses it:

# my_app.py
def call_api(prompt):
    ...  # the real network call

def answer(question):
    return call_api(question).strip()

from unittest.mock import patch

import my_app

def test_answer_strips_whitespace():
    with patch("my_app.call_api", return_value="  hi  "):
        assert my_app.answer("q") == "hi"

The one rule people forget: patch the name where it's used, not where it was defined. Here answer looks up call_api inside my_app, so that's the name we replace. Pytest's monkeypatch.setattr(my_app, "call_api", lambda prompt: " hi ") does the same job if you prefer it.

Don't overdo it

Mocks are powerful, and it's easy to go too far. A few cautions:

Fake only at the edges: the model, the network, the clock. Don't mock your own internal functions, or you'll end up testing the mocks instead of your code.
Fakes can drift. If the real model API changes and your fake doesn't, your tests pass while your app breaks. Keep a small number of tests that call the real thing, mark them, and run them only occasionally:

[tool.pytest.ini_options]
markers = ["integration: tests that call a real model API (slow, cost money)"]

@pytest.mark.integration
def test_real_model_returns_json():
    ...

Then pytest -m "not integration" runs everything except those, and pytest -m integration runs only them.

Tools that record and replay real API responses also exist, if you want realistic data without hitting the network each time.

Property-based testing: let the computer find the weird inputs

Ordinary tests check examples you thought of. The trouble is that bugs live in the examples you didn't think of. Property-based testing flips it around. You describe a rule that should be true for any input, and a tool generates hundreds of inputs to try to break it.

The standard library for this in Python is Hypothesis. Install it with pip install hypothesis. Here are two properties of our word counter:

from hypothesis import given
from hypothesis import strategies as st

from textkit.counting import count_words, top_words

@given(st.text(), st.integers(min_value=0, max_value=10))
def test_top_words_is_limited_and_sorted(text, n):
    result = top_words(text, n)
    assert len(result) <= n
    counts = [count for _, count in result]
    assert counts == sorted(counts, reverse=True)

@given(st.text())
def test_adding_a_word_adds_one_to_its_count(text):
    before = count_words(text).get("zzz", 0)
    after = count_words(text + " zzz")["zzz"]
    assert after == before + 1

@given(...) tells Hypothesis what kinds of inputs to create: any text, any whole number between 0 and 10. It then runs your test many times with different values, including nasty ones like empty strings and odd Unicode characters.

Notice we never said what the output should be for any particular input. We said what must always hold: the result is never longer than n, the counts are sorted from biggest to smallest, and adding a word once raises its count by exactly one.

When Hypothesis finds a failing input, it doesn't just show you the mess it started with. It shrinks it to the smallest failing example, which is usually much easier to understand. A function that divides by len(numbers), for example, would be caught almost instantly with the empty list [].

Properties are harder to write than examples, so don't use them for everything. They shine for code with clear rules: parsers, formatters, sorting, batching, and anything where you can say "convert it and convert it back, and you should get the original."

Running tests well

A few options you'll use constantly:

Command	What it does
pytest	Run everything
pytest -v	Show each test name
pytest -x	Stop at the first failure
pytest -k counts	Run only tests whose name contains "counts"
pytest tests/test_counting.py::test_top_words_orders_by_count	Run one specific test
pytest --lf	Re-run only the tests that failed last time
pytest -s	Show print output, which pytest hides by default
pytest --pdb	Drop into the debugger from Post 11 when a test fails

Later, in Post 28, we'll set up automatic runs so your tests execute every time you push code. A test suite that only runs when you remember is a test suite that stops running.

One last warning. You may hear about "test coverage," a percentage showing how many lines your tests ran. It's a handy way to spot code that has no tests at all. But a high number doesn't mean good tests. You can run every line and check nothing. Aim for tests that would actually catch a mistake.

Mini project: a test suite for textkit

Let's add a real test suite to the textkit package from Post 12.

Step 1. Add the replies.py module shown above to src/textkit/.

Step 2. Update the project settings in pyproject.toml:

[project.optional-dependencies]
dev = ["pytest>=8.0", "hypothesis>=6.0"]

[tool.pytest.ini_options]
testpaths = ["tests"]
markers = ["integration: tests that call a real model API (slow, cost money)"]

Step 3. Install everything:

pip install -e ".[dev]"

Step 4. Create three test files in tests/:

test_counting.py: the four example tests from earlier, plus the parametrized edge-case test.
test_replies.py: the FakeModel class, the three tests that use it, and the Mock test.
test_properties.py: the two Hypothesis tests.

Step 5. Run pytest. You should see all 13 tests pass:

tests/test_counting.py .......                                           [ 53%]
tests/test_properties.py ..                                              [ 69%]
tests/test_replies.py ....                                               [100%]

============================== 13 passed in 0.31s ==============================

(The seven in the first file are four examples plus three parametrized cases.)

Now the most important step: try to break it. Open counting.py and make a deliberate mistake, such as removing .lower(), flipping reverse=True to reverse=False, or changing ranked[:n] to ranked[:n + 1]. Run the tests and watch which ones catch it. A test that never fails isn't protecting you. Then put the code back.

Make it yours

Test the command line tool. Using monkeypatch.setattr("sys.argv", ["textkit", "the", "cat", "the"]) and the capsys fixture, call main() and check that the printed output contains the: 2.
Add an integration test, marked with @pytest.mark.integration, that would call a real model. Confirm pytest -m "not integration" skips it.
Install pytest-cov and run pytest --cov=textkit. Look at which lines have no tests.
Write a fake model that raises an error on the first call, and test how get_json_reply should behave.

Practice

About 20 minutes of real effort on each before asking for help.

Write five tests for safe_int from Post 11, using parametrize for the different inputs.
Write a test for set_temperature that uses pytest.raises with a match, and add a second test for a value on the boundary (exactly 0 and exactly 2).
Write a fixture that creates a temporary file, and use it to test read_lines from Post 7.
Take an earlier project that retries an API call. Replace the real call with a Mock(side_effect=[...]) and test the retry logic without waiting.
Write a property-based test for sorting: the result is in order, and it has the same items as the input.
Break a function on purpose, confirm a test fails with a readable message, then fix it.

Then ask an AI tutor to review your tests, and don't let it write them for you. Tests you didn't think through are the ones that give false comfort.

What to take away

Tests check your code and give the same answer every time. Evals check the model's quality, and come later.
Name files test_*.py and functions test_*, and use plain assert.
pytest.raises checks for errors, and parametrize runs one test on many inputs.
Fixtures provide reusable setup, and tmp_path and monkeypatch are two built-in ones you'll use a lot.
To test code that uses a model, swap in a fake. Pass it in as a parameter, or use Mock and patch when you can't.
Patch where a name is used, fake only at the edges, and keep a few real integration tests.
Property-based tests describe rules that must always hold, and let Hypothesis hunt for the inputs that break them.
A test is only useful if it can fail, so try breaking your code on purpose.

Previous: Post 12, Packaging & Environments

Next in the series: Post 14, Concurrency, where we cover threads, processes, asyncio, and why LLM apps are so often async.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Packaging & Environments: Modules, Virtual Environments, and pyproject.toml

Pradeep Kumar — Fri, 23 Oct 2026 06:13:26 +0000

Every programmer eventually says the same sentence: "But it works on my machine." Usually it means two computers have different versions of Python, or different libraries installed, or both.

This post is about fixing that, and it's one of the least glamorous and most useful things you'll learn. It's core. By the end you'll know how to split code into files, keep each project's libraries separate, and describe a project so anyone can install it. We'll also fix the habit from Post 10, where I told you to just run pip install and promised a tidier way later. This is the tidier way.

Modules: a file is a module

A module is just a Python file. When one file uses code from another, it imports it. You've been doing this with built-in modules like time and logging already. Now let's do it with your own.

Make a file called helpers.py:

def shout(text):
    return text.upper() + "!"

And another called main.py in the same folder:

import helpers
from helpers import shout

print(helpers.shout("hi"))    # HI!
print(shout("hello"))         # HELLO!

There are two ways to import. import helpers brings in the whole module, and you use helpers.shout. from helpers import shout brings in just that one name. Both are fine. Many people also shorten long names with as, like import numpy as np, which you'll see everywhere later.

A habit worth building: don't write from something import *. It dumps every name from the module into your file, and then nobody, including you, can tell where a name came from.

The `name` trick

Here's a pattern you'll see at the bottom of almost every script:

def shout(text):
    return text.upper() + "!"

if __name__ == "__main__":
    print(shout("testing"))

Every module has a built-in variable called __name__. When you run a file directly with python helpers.py, Python sets it to "__main__". When another file imports it, it's set to the module's name instead, which is "helpers".

So the if block runs when you run the file, and stays quiet when someone imports it. That's how one file can be both a reusable module and a runnable script.

A mistake that confuses everyone once

Python looks for imports in your current folder first. So if you name your own file after a standard library module, yours wins, and things break in confusing ways.

Say you save a file as json.py, then in another file in the same folder you write import json and call json.dumps(...):

AttributeError: module 'json' has no attribute 'dumps'

It's importing your file, not Python's. Don't name files json.py, random.py, test.py, email.py, and so on. If you ever see this kind of error and the code looks right, check your filenames.

Packages: a folder of modules

When a project grows, you group modules into a folder. A folder of modules that can be imported is called a package. A tidy layout looks like this:

textkit_project/
├── pyproject.toml
├── README.md
├── src/
│   └── textkit/
│       ├── __init__.py
│       ├── counting.py
│       └── cli.py
└── tests/

A few notes on that layout:

__init__.py marks the folder as a package, and it runs when the package is imported. It's often short, and just re-exports the main names so users can write from textkit import count_words.
Putting the package inside src/ is a common choice. It stops you from accidentally importing the local folder instead of the properly installed package, which hides bugs.
tests/ is where your tests go. That's Post 13.

Inside a package, import from your own modules using the full name, like from textkit.counting import top_words.

The problem environments solve

Now the bigger issue. When you run pip install something, it puts the library into the Python you're using. Do that for every project, and soon:

Project A needs version 1 of a library, and Project B needs version 2. You can only have one installed.
You can't tell which libraries each project really needs.
You break something on your computer's own Python that other programs depend on.

That last one is real. On many Linux systems and some Macs, installing into the system Python gets you an "externally managed environment" error. Python is protecting itself. Don't fight it with a scary flag. Use a virtual environment, which is the proper fix.

Virtual environments: one box per project

A virtual environment is a private folder holding its own Python and its own installed libraries. Each project gets one, so they never interfere.

Create one inside your project folder:

python -m venv .venv

That makes a folder called .venv. Now activate it, which tells your terminal to use that Python:

# macOS and Linux
source .venv/bin/activate

# Windows (PowerShell)
.venv\Scripts\Activate.ps1

Your prompt will usually change to show (.venv). You can double-check which Python you're using:

which python       # macOS and Linux (on Windows: where python)

It should point inside .venv. Now anything you install goes only into this box:

pip install pydantic
pip list

When you're done, type deactivate.

A few things that help:

Reproduce an environment. pip freeze > requirements.txt saves a list of what's installed, with versions. Someone else (or you, next year) can rebuild it with pip install -r requirements.txt.
Never commit .venv to Git. It's big and it's specific to your machine. Add .venv/ to your .gitignore file.
Tell your editor. In VS Code, open the command palette and choose "Python: Select Interpreter," then pick the one inside .venv. Otherwise your editor will underline imports as missing even though they work.
Wrong environment is the most common cause of ModuleNotFoundError. You installed the library in one place and ran your code in another. Check which Python is active before anything else.

uv: the modern way

The tools above work, and you should understand them. But there's a newer tool called uv that does the same jobs far faster and in one place: it creates environments, installs libraries, manages Python versions, and keeps a lock file. Many Python projects use it now, and I'd suggest you do too.

You can install it with pip install uv, or use the standalone installer from its official site (docs.astral.sh/uv). Tools in this area change quickly, so if a command here doesn't match what you see, check the official docs.

Starting a new project:

uv init my_app
cd my_app

That creates a small project: a pyproject.toml, a README.md, a main.py, a .python-version file that says which Python to use, and a .gitignore that already excludes .venv. (The exact files vary a little between versions. It also sets up a Git repository for you.)

Adding a library:

uv add pydantic

That does three things at once: it creates the virtual environment if there isn't one, installs the library, and records it in pyproject.toml. It also writes a uv.lock file that pins the exact versions of everything. Run your code with:

uv run main.py

uv run always uses the project's environment, so you never have to remember to activate anything. If a friend clones your project, one command, uv sync, rebuilds the exact same environment.

Here's how the two approaches compare:

Job	pip and venv	uv
Create an environment	python -m venv .venv	automatic
Activate it	source .venv/bin/activate	not needed with uv run
Add a library	pip install name	uv add name
Record dependencies	pip freeze > requirements.txt	automatic in pyproject.toml and uv.lock
Rebuild on another machine	pip install -r requirements.txt	uv sync

Which should you use? Whichever your team or tutorial uses. If you're free to choose, pick uv. This series will show the simplest version of each command, and the ideas are identical either way.

pyproject.toml: the project's ID card

pyproject.toml is a single file that describes your project. Nearly every modern Python tool reads it. Here's the one for the small project we'll build below:

[project]
name = "textkit"
version = "0.1.0"
description = "Small tools for counting words in text"
readme = "README.md"
requires-python = ">=3.11"
dependencies = []

[project.optional-dependencies]
dev = ["pytest>=8.0"]

[project.scripts]
textkit = "textkit.cli:main"

[build-system]
requires = ["setuptools>=68"]
build-backend = "setuptools.build_meta"

The format is called TOML. It's plain text with sections in square brackets. What each part does:

[project] has the basics: the name, the version, a description, and the oldest Python it supports. dependencies lists the libraries your project needs to run. Ours is empty because it only uses Python itself.
[project.optional-dependencies] lists extras. Here, pytest is only needed by people working on the project, not by people using it, so it goes in a dev group.
[project.scripts] turns a function into a command. The line says: create a command called textkit that runs the main function in textkit/cli.py. After installing, you can type textkit in your terminal.
[build-system] says which tool turns your folder into an installable package. setuptools is the long-standing choice. Others, like hatchling, work too, and you'll see them in plenty of projects. You rarely need to care which.

Many other tools, such as test runners and code formatters, also read settings from the same file, which keeps your project in one place.

Versions and lock files

Dependencies usually come with a version rule:

Written as	Meaning
pydantic>=2.0	Version 2.0 or newer
pydantic==2.5.1	Exactly this version
pydantic~=2.5	2.5 or newer, but below 3.0
pydantic>=2.0,<3	At least 2.0, but below 3

Loose rules in pyproject.toml say what your project can work with. A lock file (uv.lock, or a pinned requirements.txt) records the exact versions you actually tested, including libraries your libraries depend on. Together they give you flexibility on paper and reliability in practice.

A quick word on trust. Installing a library runs other people's code on your computer. Before you install something, check that you've spelled the name right (fake packages with near-identical names do exist), and that it's a real, maintained project. It takes ten seconds and avoids a lot of trouble.

Another kind of environment: environment variables

AI work adds one more thing. You'll use API keys, which are like passwords for model services. They must never appear in your code or in Git.

The standard solution is an environment variable, a setting that lives outside your code:

import os

api_key = os.environ.get("MODEL_API_KEY")
if api_key is None:
    raise RuntimeError("Set the MODEL_API_KEY environment variable first")

For local work, people keep their variables in a file called .env:

MODEL_API_KEY=your-key-goes-here

Then they load it at startup with a library like python-dotenv (load_dotenv()). The rules:

Add .env to .gitignore so it never gets uploaded.
Commit a .env.example file with the names but fake values, so others know what to set.
If a key ever does leak, treat it as stolen: revoke it and make a new one.

Mini project: your first package

Let's turn the word counter from Post 5 into a real package you can install, with its own command. Build the folder layout shown earlier. First, src/textkit/counting.py:

def count_words(text: str) -> dict[str, int]:
    """Count how often each word appears in a piece of text."""
    words = text.lower().replace(".", "").replace(",", "").split()
    counts: dict[str, int] = {}
    for word in words:
        counts[word] = counts.get(word, 0) + 1
    return counts

def top_words(text: str, n: int = 5) -> list[tuple[str, int]]:
    """Return the n most common words with their counts."""
    counts = count_words(text)
    ranked = sorted(counts, key=counts.get, reverse=True)
    return [(word, counts[word]) for word in ranked[:n]]

Then src/textkit/__init__.py:

from textkit.counting import count_words, top_words

__all__ = ["count_words", "top_words"]

And src/textkit/cli.py:

import sys

from textkit.counting import top_words

def main() -> None:
    text = " ".join(sys.argv[1:]) or sys.stdin.read()
    for word, count in top_words(text):
        print(f"{word}: {count}")

if __name__ == "__main__":
    main()

Add the pyproject.toml from above, and a README.md containing a title. Now create an environment and install your package in editable mode, which means changes to your code take effect immediately without reinstalling:

python -m venv .venv
source .venv/bin/activate        # on Windows, use the activate line from earlier
pip install -e .

(With uv, the equivalent is uv pip install -e . inside a project, or you can structure it as a uv project from the start with uv init --lib.)

Now try it from any folder:

python -c "import textkit; print(textkit.top_words('The cat sat on the mat. The dog sat on the log.', n=3))"
# [('the', 4), ('sat', 2), ('on', 2)]

textkit the cat sat on the mat
# the: 2
# cat: 1
# sat: 1
# on: 1
# mat: 1

echo "the dog and the cat" | textkit
# the: 2
# dog: 1
# and: 1
# cat: 1

Take a moment to appreciate that. You typed textkit in a terminal, and your own code ran. It's no longer a script in a folder. It's a package, with a name, a version, and a command.

Notice, too, that pip list now shows textkit with the path of your folder next to it. That's what "editable" means.

Make it yours

Add a clean.py module with a function that removes punctuation more thoroughly, and use it from counting.py.
Add a real dependency, such as rich for colored output, and see how it shows up in pyproject.toml.
Add a --top 10 option to the command. (Look up argparse in the Python docs.)
Repeat the whole thing with uv, and compare the steps.

Practice

About 20 minutes of real effort on each before asking for help.

Create a virtual environment, install a library, and confirm it with pip list. Then delete the environment and rebuild it from a requirements.txt file.
Make two environments. Install requests in only one of them. Show that import requests works in one and fails in the other.
Break things on purpose: create a file called json.py, and watch what happens to a script that imports json.
Write a module that behaves differently when it's imported than when it's run directly, using if __name__ == "__main__":.
Write a .gitignore for the project above and explain each line in your own words.
Find a small open-source Python project on GitHub, open its pyproject.toml, and list its dependencies.

Then ask an AI tutor to review your answers, and don't let it rewrite them.

What to take away

A module is a Python file, and a package is a folder of modules.
if __name__ == "__main__": lets a file work both as a script and as an importable module.
Never name your files after standard library modules.
A virtual environment gives each project its own libraries, so projects can't interfere with each other.
uv does everything pip and venv do, faster and in one tool, but the ideas are the same.
pyproject.toml describes your project: its name, Python version, dependencies, and commands.
Lock files pin exact versions so every machine gets the same setup.
API keys belong in environment variables, never in code or Git.

Previous: Post 11, Errors, Logging & Debugging

Next in the series: Post 13, Testing with pytest, where we write tests, mock model calls, and stop worrying about breaking things.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Decorators & Context Managers: The @ and with You Keep Seeing

Pradeep Kumar — Wed, 21 Oct 2026 06:46:37 +0000

Open almost any modern Python project and you'll spot two things quickly. Lines that start with @, like @app.get("/hello"). And blocks that start with with, like with torch.no_grad():.

They look like magic if nobody explains them. They're not. Both are built from ideas you already met: functions as values and closures from Post 6, and generators from Post 7. This post is core, because FastAPI, PyTorch, and plenty of AI libraries lean on both.

The problem decorators solve

Say you want to know how long a function takes. You could add timing code to it. Then you want the same for five other functions. Then you want to add logging. Soon every function is half timing code and half the thing it was meant to do.

What you'd like is a way to wrap extra behavior around a function without touching its insides. That's what a decorator does.

Building a decorator by hand

A decorator is a function that takes a function and returns a new, improved function. Here's one that measures time:

import time

def timed(func):
    def wrapper(*args, **kwargs):
        start = time.perf_counter()
        result = func(*args, **kwargs)
        elapsed = time.perf_counter() - start
        print(f"{func.__name__} took {elapsed:.3f} seconds")
        return result
    return wrapper

Take it slowly, because everything in there comes from Post 6:

timed takes a function called func.
Inside, it defines wrapper, a new function that starts a clock, calls the original func, stops the clock, prints the time, and returns the original result.
*args and **kwargs let the wrapper accept whatever the original function accepts and pass it along.
wrapper is a closure. It remembers func after timed has finished.
timed returns wrapper, without calling it.

Now use it:

def slow_add(a, b):
    time.sleep(0.5)
    return a + b

slow_add = timed(slow_add)

print(slow_add(2, 3))
# slow_add took 0.500 seconds
# 5

We replaced slow_add with the wrapped version. Python has a shortcut for exactly this pattern, and that's the @ symbol:

@timed
def slow_add(a, b):
    time.sleep(0.5)
    return a + b

Those two versions do the same thing. @timed above a function simply means slow_add = timed(slow_add). That's all it is.

A small fix: functools.wraps

There's one annoying side effect. After decorating, the function forgets who it is:

print(slow_add.__name__)    # wrapper

That's because slow_add is now really the wrapper function. It can mess up error messages, logs, and tools that look at function names. The standard fix is to add @wraps(func) to the wrapper:

from functools import wraps

def timed(func):
    @wraps(func)
    def wrapper(*args, **kwargs):
        start = time.perf_counter()
        result = func(*args, **kwargs)
        elapsed = time.perf_counter() - start
        print(f"{func.__name__} took {elapsed:.3f} seconds")
        return result
    return wrapper

Now slow_add.__name__ correctly says slow_add. Treat @wraps as a habit you always include. It's a decorator that's used inside a decorator, which is a fun thing to notice.

Decorators that take settings

Often you want to customize a decorator, like @retry(attempts=5). That needs one more layer, and this is the part that confuses everyone at first. Here's the retry helper from Post 6, rewritten as a decorator:

def retry(attempts=3, delay=0.5):
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            for attempt in range(1, attempts + 1):
                try:
                    return func(*args, **kwargs)
                except Exception as error:
                    print(f"Attempt {attempt} failed: {error}")
                    if attempt == attempts:
                        raise
                    time.sleep(delay)
        return wrapper
    return decorator

Three layers, each with one job:

retry(...) takes the settings and returns a decorator.
decorator(func) takes the function and returns the wrapper.
wrapper(...) is what actually runs each time you call the function.

So @retry(attempts=5) first calls retry(attempts=5), which hands back a decorator, and then that decorator is applied to the function below it. If three layers feels like a lot, it is. Read it twice, then type it out yourself.

Decorators that register instead of wrap

Not every decorator changes the function. Some just make a note of it and hand it back unchanged. This is how web frameworks find your route handlers, and it's how many AI frameworks keep track of the tools a model is allowed to call.

tools = {}

def tool(func):
    tools[func.__name__] = func
    return func

@tool
def get_weather(city):
    return f"Sunny in {city}"

print(tools["get_weather"]("Lisbon"))    # Sunny in Lisbon
print(list(tools))                       # ['get_weather']

Remember the dictionary of functions from Post 6? This is the tidy version. Mark a function with @tool and it lands in the registry. When a model asks for get_weather by name, you look it up and run it.

When you see @app.get("/hello") in FastAPI, it's the same family of idea: it tells the framework "when someone visits /hello, run this function."

A few built-in decorators worth knowing

@cache (from functools) remembers results, so calling a function again with the same input returns instantly:

from functools import cache

@cache
def expensive_lookup(word):
    print(f"Computing for {word}...")
    return len(word) * 10

print(expensive_lookup("hello"))    # Computing for hello...  then 50
print(expensive_lookup("hello"))    # 50  (no computing this time)

Two warnings. The inputs must be things that can be dictionary keys, so passing a list fails (remember Post 5). And don't cache anything where you want a fresh answer each time, like most model calls.

@staticmethod, @property, and @dataclass show up when we cover classes in the next post.

Context managers: cleaning up after yourself

Now the with statement. Some things need to be opened and then closed properly: files, network connections, database sessions, locks. If you forget to close them, or your program crashes in the middle, you get leaks and strange bugs.

You've already seen the fix:

with open("demo.txt", "w", encoding="utf-8") as file:
    file.write("hello")

print(file.closed)    # True

When the with block ends, the file is closed. Always. Even if an error happens inside the block. That guarantee is the whole point.

You can open more than one thing in the same line:

with open("demo.txt") as src, open("copy.txt", "w") as dst:
    dst.write(src.read())

How `with` works

Anything that works with with is called a context manager. It's an object with two special methods: one that runs when you enter the block, and one that runs when you leave, no matter how you leave. Here's a timer built that way:

import time

class Timer:
    def __enter__(self):
        self.start = time.perf_counter()
        return self

    def __exit__(self, exc_type, exc_value, traceback):
        self.elapsed = time.perf_counter() - self.start
        print(f"Took {self.elapsed:.2f} seconds")
        return False

with Timer():
    time.sleep(0.3)
# Took 0.30 seconds

We haven't covered classes yet (that's Post 9), so just read this as a recipe for now. __enter__ is the setup. __exit__ is the cleanup. If an error happened inside the block, the three extra arguments describe it, and returning False means "let the error carry on."

The easy way: `@contextmanager`

Writing a whole class for a small job is a bit much. Python has a shortcut that uses a generator, which you met in Post 7. Everything before yield is setup, and everything after is cleanup:

from contextlib import contextmanager
import time

@contextmanager
def timer(label):
    start = time.perf_counter()
    try:
        yield
    finally:
        elapsed = time.perf_counter() - start
        print(f"{label} took {elapsed:.2f} seconds")

with timer("sleeping"):
    time.sleep(0.3)
# sleeping took 0.30 seconds

The try and finally matter. Code in finally always runs, even if the block inside with raises an error. So the timer still reports in a crash:

with timer("crashing"):
    raise ValueError("oops")
# crashing took 0.00 seconds
# then the ValueError appears as usual

Notice how this ties together. @contextmanager is a decorator, wrapped around a generator, producing something you use with with. If that sentence made sense, you've understood the last three posts.

Where you'll see these in AI work

with torch.no_grad(): switches off gradient tracking while you run a model for predictions, then switches it back on afterward. You'll write it often once we reach PyTorch. (It can also be used as a decorator, so you'll see both styles.)
Network and database sessions that must close cleanly.
Temporary settings, like running a block of code with a different configuration and then restoring the original.
Timing and tracing blocks of code, like our timer.
Route handlers and tools registered with decorators in web and agent frameworks.

Mini project: a small toolkit

Let's combine everything in one file. Create toolkit.py with the timed decorator, the retry decorator, and the timer context manager from above, then add this at the bottom:

import random

@timed
@retry(attempts=4, delay=0.1)
def fake_model_call(prompt):
    time.sleep(0.2)
    if random.random() < 0.5:
        raise RuntimeError("Model busy")
    return f"Answer to: {prompt}"

with timer("whole batch"):
    for prompt in ["What is a decorator?", "What is a context manager?"]:
        print(fake_model_call(prompt))

Run it a few times. The failures are random, so every run looks a little different. A run with one failed attempt might print:

Attempt 1 failed: Model busy
fake_model_call took 0.500 seconds
Answer to: What is a decorator?
fake_model_call took 0.200 seconds
Answer to: What is a context manager?
whole batch took 0.70 seconds

A detail worth noticing: when you stack decorators, the one closest to the function is applied first. So @retry wraps the function, and then @timed wraps that. That means the time you see includes the retries and the waiting between them. If you swapped the two lines, timed would report only a single attempt each time.

You've just written the core of a tool that real AI apps need: a function that measures itself, tries again when it fails, and sits inside a timed block. And none of that code is inside the function that makes the model call.

Make it yours

Add a @log_calls decorator that prints the function name and its arguments before each call.
Write your own simple cache using a dictionary, then compare it with @cache.
Write a context manager that temporarily changes a value in a dictionary and puts the original back afterward.
Add a max_total_seconds setting to retry so it gives up if too much time has passed.

Practice

About 20 minutes of real effort on each before asking for help.

Write a @shout decorator that makes any function's returned text uppercase.
Write a @count_calls decorator that keeps track of how many times a function has been called. (Hint: you can store the count on the wrapper itself, like wrapper.calls = 0.)
Write a context manager with @contextmanager that prints "Entering" when the block starts and "Leaving" when it ends, even if there's an error.
Use @cache on a recursive Fibonacci function and compare how long fib(35) takes with and without it.
Without using @, write the exact equivalent of decorating a function with @timed.

Then ask an AI tutor to review your code, not rewrite it.

What to take away

A decorator is a function that takes a function and returns a new one. @name is just a shortcut for func = name(func).
Use @wraps(func) inside every decorator you write.
A decorator with settings has three layers: settings, function, wrapper.
Some decorators wrap, and some simply register a function and return it unchanged.
A context manager guarantees setup and cleanup around a block of code, even when something goes wrong.
@contextmanager lets you build one with a generator and a try/finally.

Previous: Post 7, Iterators, Generators & Comprehensions

Next in the series: Post 9, OOP the Practical Way, where we cover classes, dataclasses, and when to use composition instead of inheritance.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Iterators, Generators & Comprehensions: How Python Handles Streams of Data

Pradeep Kumar — Wed, 21 Oct 2026 06:45:33 +0000

When you chat with an AI model and the answer appears word by word, instead of all at once, something specific is happening in the code. The text is arriving in small pieces, and your program is handling each piece as it shows up.

The Python feature behind that is called a generator. This post explains generators, along with the ideas they're built on: comprehensions and iterators. They're core, so I'd read them all. You'll use them for reading big datasets, building pipelines, batching requests, and streaming model output.

Comprehensions: loops in one line

Here's a loop you've probably written something like before. It builds a list of squares:

numbers = [1, 2, 3, 4, 5, 6]

squares = []
for n in numbers:
    squares.append(n * n)

A list comprehension does the same job in one line:

squares = [n * n for n in numbers]
print(squares)    # [1, 4, 9, 16, 25, 36]

Read it like English: "give me n * n for each n in numbers."

You can add a filter at the end:

evens = [n for n in numbers if n % 2 == 0]
print(evens)    # [2, 4, 6]

And combine the two:

words = ["banana", "fig", "cherry", "kiwi"]

print([w.upper() for w in words if len(w) > 3])
# ['BANANA', 'CHERRY', 'KIWI']

Remember map and filter from the last post? Comprehensions do the same things, and most Python programmers find them easier to read. You'll see them far more often.

The same idea works for dictionaries and sets, just with different brackets:

print({w: len(w) for w in words})
# {'banana': 6, 'fig': 3, 'cherry': 6, 'kiwi': 4}

print({len(w) for w in words})
# {3, 4, 6}

You can even loop over a list of lists in one go. Read it left to right, like two loops stacked together:

grid = [[1, 2], [3, 4], [5]]
print([x for row in grid for x in row])
# [1, 2, 3, 4, 5]

One piece of advice: comprehensions are for simple jobs. If you find yourself squeezing in several conditions and nested logic, a normal loop is kinder to whoever reads it next, and that person is often you in three months.

What a for loop really does

Let's look under the hood of for. Two words matter here.

An iterable is anything you can loop over: a list, a string, a dictionary, a file.
An iterator is the object that actually hands out the items one at a time and remembers where it is.

You can see this by hand with iter() and next():

letters = ["a", "b", "c"]
it = iter(letters)

print(next(it))    # a
print(next(it))    # b
print(next(it))    # c
print(next(it))    # StopIteration error

When there's nothing left, Python raises a StopIteration signal. A for loop is just a tidy wrapper around exactly this: it asks for an iterator, keeps calling next, and quietly stops when it sees StopIteration.

Here's the part that catches people out. An iterator gets used up:

it = iter([1, 2, 3])
print(list(it))    # [1, 2, 3]
print(list(it))    # []

The second time, there's nothing left, so you get an empty list. Keep that in mind, because generators behave the same way.

Two built-in helpers you'll use all the time. enumerate gives you a counter along with each item, and zip walks through two lists side by side:

for i, word in enumerate(["a", "b"], start=1):
    print(i, word)
# 1 a
# 2 b

questions = ["q1", "q2", "q3"]
answers = ["a1", "a2"]

for q, a in zip(questions, answers):
    print(q, a)
# q1 a1
# q2 a2

Notice that zip stops at the shorter list. The third question quietly disappears. That's useful to know when you pair up questions and answers in an evaluation set.

Generators: functions that pause

Now the main event. A normal function runs from top to bottom and returns once. A generator function can hand back a value, pause right there, and pick up where it left off the next time you ask. The magic word is yield.

def count_up(limit):
    n = 1
    while n <= limit:
        yield n
        n += 1

for number in count_up(3):
    print(number)
# 1
# 2
# 3

Instead of return, it uses yield. Each time the loop asks for a value, the function runs until it hits yield, hands the value over, and freezes. When the loop asks again, it wakes up on the line after yield.

To see how lazy that really is, add some prints:

def noisy():
    print("starting")
    yield 1
    print("middle")
    yield 2
    print("done")

gen = noisy()
print("created")
print(next(gen))
print(next(gen))

Output:

created
starting
1
middle
2

Look at the order. Creating the generator printed nothing. The function body doesn't start until the first next(). And "done" hasn't shown up yet, because we never asked for a third value. Generators do work only when you ask, and only as much as you ask for.

Just like iterators, a generator is used up after one pass.

Why lazy matters: memory

Here's the real payoff. Compare building a million squares as a list with a generator:

import sys

big_list = [n * n for n in range(1_000_000)]
big_gen = (n * n for n in range(1_000_000))

print(sys.getsizeof(big_list))    # about 8,000,000 bytes
print(sys.getsizeof(big_gen))     # about 200 bytes

The only difference in the code is the brackets. Square brackets build the whole list in memory right now. Round brackets make a generator expression, which holds almost nothing and produces each value when asked. (The list's size doesn't even count the numbers inside it, so the real gap is bigger.)

A million numbers is no problem for a modern computer. But replace that with a dataset of 50 million text records and it's a different story. With a generator, your program handles one record at a time, and memory stays small whether the file has a thousand lines or a billion.

Functions like sum, max, and any accept generator expressions directly, no extra brackets needed:

print(sum(n * n for n in range(10)))    # 285

Reading big files, one line at a time

Files are lazy too. Looping over a file gives you one line at a time, without loading the whole thing:

def read_lines(path):
    with open(path, encoding="utf-8") as file:
        for line in file:
            yield line.strip()

(The with line makes sure the file gets closed properly. We'll cover that in the next post.)

Now you can chain generators together into a pipeline, where each step takes one item, does something, and passes it on:

def keep_real_text(lines, min_length=20):
    for line in lines:
        if len(line) >= min_length:
            yield line

Neither step ever holds the whole dataset. One line flows through at a time. This is how people clean huge text collections for AI training and search without needing a monster computer.

Streaming model output

Now back to where we started. When you ask a model to stream its reply, the answer arrives in small chunks as it's produced. Many model libraries hand you those chunks as something you can loop over, which means a generator or an iterator under the hood.

You can fake the whole thing to feel how it works:

import time

def fake_model_stream(text):
    for word in text.split():
        time.sleep(0.2)
        yield word + " "

for chunk in fake_model_stream("Generators make streaming feel natural"):
    print(chunk, end="", flush=True)
print()

Run it and the sentence appears one word at a time. Two small details: end="" stops print from adding a new line after each chunk, and flush=True makes the text show on screen immediately instead of waiting.

When we build our first LLM app in Post 49, the code that handles a streamed reply will look almost exactly like this loop.

Batching: a pattern you'll use constantly

AI services often work better, and cheaper, when you send items in groups instead of one by one. Embedding thousands of documents is a classic case. So you need a way to chop a stream of items into batches.

For a list, it's quick:

def batches_list(items, size):
    for start in range(0, len(items), size):
        yield items[start:start + size]

for batch in batches_list(list(range(10)), 4):
    print(batch)
# [0, 1, 2, 3]
# [4, 5, 6, 7]
# [8, 9]

But that needs the whole list in memory. In the mini project below, we'll write a version that works on any stream.

(If you're on Python 3.12 or newer, there's also itertools.batched, which does this for you. It's good to know, and it's even better to have written one yourself first.)

Mini project: a lazy text pipeline

Let's put it all together. We'll read a file line by line, throw away blank and very short lines, and group what's left into batches of three, like you would before sending text to an embedding service. We won't call any real service. We'll just count.

First, create a file called notes.txt with this content (include the blank line):

Python generators are lazy and save memory.

ok
A batch groups several items together before processing.
Streaming sends output in small chunks as it is made.
short line
Comprehensions are a compact way to build collections.
Iterators remember where they are in a sequence.
Decorators come in the next post of this series.

Then create pipeline.py:

def read_lines(path):
    with open(path, encoding="utf-8") as file:
        for line in file:
            yield line.strip()

def keep_real_text(lines, min_length=20):
    for line in lines:
        if len(line) >= min_length:
            yield line

def batches(items, size):
    batch = []
    for item in items:
        batch.append(item)
        if len(batch) == size:
            yield batch
            batch = []
    if batch:
        yield batch

lines = read_lines("notes.txt")
good_lines = keep_real_text(lines)

for number, batch in enumerate(batches(good_lines, size=3), start=1):
    print(f"Batch {number}: {len(batch)} lines")

You should see:

Batch 1: 3 lines
Batch 2: 3 lines

Here's the thing worth noticing. The two lines that create lines and good_lines do no work at all. They just set up the pipeline. The reading, filtering, and batching only happen once the for loop at the bottom starts asking for values. And at any moment, only a few lines are in memory.

The batches function collects items into a small list, yields it when it's full, and then yields whatever is left over at the end. That last if batch: check is easy to forget, and without it you'd lose the final partial batch.

Make it yours

Print the first 40 characters of each line in a batch.
Replace the print with a fake embed(batch) function that returns the length of each line.
Use itertools.islice to process only the first 100 lines.
Generate a file with a million lines and run the pipeline on it. Then change read_lines to return a list instead, and compare how the memory use feels.

Practice

About 20 minutes of real effort on each.

Use a comprehension to turn a sentence into a list of its word lengths.
Use two lists and a dictionary comprehension (with zip) to build a dictionary from names and ages.
Write a generator countdown(n) that yields n, then n - 1, down to 1.
Write a generator fibonacci() that goes on forever, and use a loop with break to print the first 10 numbers.
Change read_lines so it only yields lines that contain a keyword you pass in.

After you've tried, ask an AI tutor to review your code, not rewrite it.

What to take away

A comprehension builds a list, dictionary, or set in one readable line.
A for loop asks an iterable for an iterator and calls next until StopIteration.
Iterators and generators get used up after one pass.
A generator uses yield to hand back one value at a time and pause in between.
Generators are lazy, so they keep memory small and let you work with data of any size.
Streaming model output, file pipelines, and batching all rely on this idea.

Previous: Post 6, Functions in Depth

Next in the series: Post 8, Decorators & Context Managers, which explains the with statement and the @ lines you'll see all over FastAPI and PyTorch code.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Functions in Depth: Scope, Closures, and Passing Functions Around

Pradeep Kumar — Wed, 21 Oct 2026 06:19:02 +0000

In Post 4 you wrote simple functions that take an input and return an output. That's the easy part. This post goes into the parts that confuse people later, and the parts that show up everywhere in AI code.

This one is core, so I wouldn't skip it, even if you've written Python before. Functions that take other functions as input are all over the place in modern AI work. Callbacks, decorators, and the way a model asks your code to run a tool all depend on the ideas below.

A quick recap, plus a trap

You can pass arguments by position or by name:

def describe(name, age=30):
    return f"{name} is {age}"

print(describe("Asha"))              # Asha is 30
print(describe("Asha", 25))          # Asha is 25
print(describe(age=41, name="Ravi")) # Ravi is 41

Passing by name is clearer, and you'll do it a lot with AI libraries, where a call might have a dozen options.

Now the trap. Look at this function:

def add_item(item, items=[]):
    items.append(item)
    return items

print(add_item("a"))    # ['a']
print(add_item("b"))    # ['a', 'b']   <- wait, what?

The second call should have returned ['b']. It didn't, because Python makes the default list once, when the function is defined, and then reuses that same list on every call. Changes pile up.

The fix is to use None as the default and make the list inside:

def add_item(item, items=None):
    if items is None:
        items = []
    items.append(item)
    return items

Rule of thumb: never use a list or dictionary as a default value.

`*args` and `**kwargs`: any number of arguments

Sometimes you don't know how many arguments a function will get. A star in front of a parameter name collects extras.

def total(*numbers):
    return sum(numbers)

print(total(1, 2, 3))    # 6
print(total())           # 0

Inside the function, numbers is a tuple holding everything that was passed in.

Two stars collect named arguments into a dictionary:

def show(**options):
    for key, value in options.items():
        print(key, value)

show(model="x", temperature=0.2)
# model x
# temperature 0.2

The names are just convention: *args and **kwargs are what most people write. The stars are what matter.

The stars also work in reverse, when you call a function. They spread out a collection into separate arguments:

numbers = (1, 2, 3)
print(total(*numbers))            # same as total(1, 2, 3)

config = {"model": "y", "temperature": 0.5}
show(**config)                    # same as show(model="y", temperature=0.5)

Why does this matter for AI work? You'll often write a function that wraps another one and just passes everything along. A wrapper around an API call, for example, shouldn't have to list every option the API supports. It collects them with **kwargs and hands them over.

Scope: where a variable lives

A variable made inside a function belongs to that function only.

def local_only():
    secret = 42

local_only()
print(secret)    # NameError: name 'secret' is not defined

Python looks for names in a set order: first inside the current function (local), then in any function wrapped around it, then at the top of your file (global), and finally in Python's built-in names like len and print.

Now a puzzle that catches nearly everyone once:

counter = 0

def increase():
    counter = counter + 1

increase()

UnboundLocalError: cannot access local variable 'counter' where it is not associated with a value

You'd expect that to work, since counter clearly exists above. The problem is that when you assign to a name inside a function, Python decides that name is local to the function. So on the right-hand side it looks for a local counter that doesn't exist yet.

You can fix it with the global keyword, but I'd avoid that. Code that secretly changes outside variables gets very hard to follow. The cleaner way is to pass things in and return things out:

def increase(counter):
    return counter + 1

counter = increase(counter)

Functions are just values

This is the big idea of the post. In Python, a function is an object like any other. You can put it in a variable, a list, or a dictionary, and pass it to another function.

def shout(text):
    return text.upper()

def whisper(text):
    return text.lower()

styles = {"shout": shout, "whisper": whisper}

print(styles["shout"]("hello"))      # HELLO
print(styles["whisper"]("HELLO"))    # hello

Notice there are no brackets after shout and whisper when they go into the dictionary. Writing shout means "the function itself." Writing shout("hi") means "run it now."

That dictionary trick comes back later. When a language model decides it wants to use a tool, it sends back the name of the tool as text. Your code looks that name up in a dictionary like this one and runs the matching function. That's all tool calling is, at its core.

Higher-order functions

A function that takes another function as input, or returns one, is called a higher-order function. It sounds fancy, but you've already used one.

def apply_to_all(func, items):
    return [func(item) for item in items]

print(apply_to_all(shout, ["a", "b"]))    # ['A', 'B']

Python's built-in sorted() is one too. It takes an optional key that tells it how to sort:

words = ["banana", "fig", "cherry"]
print(sorted(words, key=len))    # ['fig', 'banana', 'cherry']

Here len is passed as a function. Python calls it on each word and sorts by the results: 6, 3, 6. That also explains the line from Post 5: sorted(counts, key=counts.get) sorts the words by looking up each one's count.

Lambdas: tiny throwaway functions

Sometimes you need a small function just once, and giving it a name feels like overkill. A lambda is a function written in one line, with no name:

square = lambda x: x * x
print(square(4))    # 16

The part before the colon is the input, and the part after is the result. Lambdas shine as quick arguments:

words = ["banana", "fig", "cherry"]
print(sorted(words, key=lambda w: len(w)))    # ['fig', 'banana', 'cherry']

Two other built-ins that take functions are filter (keep the items that pass a test) and map (transform every item):

numbers = [1, 2, 3, 4, 5, 6]

print(list(filter(lambda n: n % 2 == 0, numbers)))    # [2, 4, 6]
print(list(map(lambda n: n * n, numbers)))            # [1, 4, 9, 16, 25, 36]

A word of advice. Keep lambdas short. If you need more than one simple expression, or if you'd like to give it a good name, write a regular def. Also, in the next post you'll meet comprehensions, which are often a nicer way to do what map and filter do.

Closures: functions that remember

Here's one that makes people pause the first time. You can define a function inside another function, and the inner one can use the outer one's variables, even after the outer function has finished.

def make_multiplier(factor):
    def multiply(number):
        return number * factor
    return multiply

double = make_multiplier(2)
triple = make_multiplier(3)

print(double(5))    # 10
print(triple(5))    # 15

When make_multiplier(2) finishes, you'd think factor disappears. It doesn't. The inner function carries it along. That's called a closure, and double and triple each remember their own factor.

It's useful any time you want to build a configured function. A more AI-flavored example:

def make_prompt_builder(role):
    def build(question):
        return f"You are a {role}. Answer this question: {question}"
    return build

teacher = make_prompt_builder("patient teacher")
print(teacher("What is a closure?"))
# You are a patient teacher. Answer this question: What is a closure?

You set the role once, and then reuse the builder as many times as you like.

A closure can also hold state that changes over time. For that you need the nonlocal keyword, which says "I mean the variable from the outer function, not a new local one":

def make_counter():
    count = 0
    def increment():
        nonlocal count
        count += 1
        return count
    return increment

counter = make_counter()
print(counter(), counter(), counter())    # 1 2 3

Closures are the idea behind decorators, which is the topic of the next-but-one post. So if this section felt abstract, read it again slowly before moving on.

Habits for writing good functions

One job per function. If you need "and" to describe what it does, it's probably two functions.
Pick a clear name. calculate_cost beats process.
Add a docstring. A short description right under the def line:

def calculate_cost(tokens, price_per_million):
    """Return the cost in dollars for a number of tokens."""
    return tokens / 1_000_000 * price_per_million

Your editor will show it when you hover over the function, and your future self will thank you.

Mini project: a retry helper

API calls fail. The network drops, a server is busy, you hit a rate limit. Real AI apps need to try again, and you don't want to copy the same retry code around every place you call a model.

This is the perfect job for a higher-order function. Create retry.py:

import random
import time

def retry(func, *args, attempts=3, delay=0.5, **kwargs):
    for attempt in range(1, attempts + 1):
        try:
            return func(*args, **kwargs)
        except Exception as error:
            print(f"Attempt {attempt} failed: {error}")
            if attempt == attempts:
                raise
            time.sleep(delay)

def flaky_greeting(name):
    if random.random() < 0.6:
        raise RuntimeError("Service busy")
    return f"Hello, {name}!"

print(retry(flaky_greeting, "Asha", attempts=5))

Run it a few times. Since the failures are random, the output changes. You might see something like this:

Attempt 1 failed: Service busy
Attempt 2 failed: Service busy
Hello, Asha!

Occasionally all five attempts fail and you'll see the error crash the program. That's expected. When the last attempt fails, the function re-raises the error instead of hiding it.

Here's what's going on. retry takes any function, plus whatever arguments that function needs, collected with *args and **kwargs. It calls the function inside a try block. A try/except means "try this, and if it crashes, do this instead." (We'll cover it properly in Post 11.) Because retry doesn't care what the function does, the same helper works for any function that might fail.

One detail: attempts and delay come after *args. That means they can only be given by name, like attempts=5. It stops you from mixing them up with the arguments for your own function.

Make it yours

Make the delay double after every failed attempt (this is called exponential backoff, and real APIs expect it).
Only retry on certain errors, and let others crash right away.
Print how long all the attempts took in total.

Practice

About 20 minutes of real effort on each before you ask for help.

Write a function that takes any number of numbers and returns their average.
Write make_greeter(greeting) that returns a function. make_greeter("Namaste")("Asha") should give "Namaste, Asha!".
Sort a list of names by their last letter, using a lambda.
Write your own apply_to_all(func, items) without using map or a list comprehension.
Fix this so repeated calls don't share a list:

def collect(value, bucket={}):
    bucket[value] = True
    return bucket

Then ask an AI tutor to review your answers, and don't let it rewrite them.

What to take away

Arguments can be passed by position or by name, and *args and **kwargs collect the extras.
Never use a list or dictionary as a default value.
A variable made inside a function stays inside it.
Functions are values, so you can store them, pass them, and return them.
Lambdas are small one-line functions, best for short jobs.
A closure is a function that remembers variables from where it was created.

Previous: Post 5, Built-in Data Structures

Next in the series: Post 7, Iterators, Generators & Comprehensions, the tools behind data pipelines and streaming model output.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Built-in Data Structures: Lists, Dicts, Sets, and Tuples

Pradeep Kumar — Wed, 21 Oct 2026 06:18:37 +0000

In the last post you stored single values: a name, a number, a piece of text. Real programs deal with collections. A list of chat messages. A dictionary of settings. A pile of documents where you need to know which ones you've already seen.

Python gives you four built-in containers for this, and they cover most of what you'll write for a long time. Learning which one to reach for, and why, is one of the best early investments you can make.

This post is skippable if you already know them well. Here's a test. What does this print?

seen = set()
for word in ["a", "b", "a", "c", "b"]:
    seen.add(word)
print(len(seen))

If you said 3, and you could explain why a set is a better choice than a list for "have I seen this before?" questions, skip to Post 6. Otherwise, keep reading.

Lists: an ordered collection you can change

A list holds items in order. You can add to it, remove from it, and change it.

prompts = ["summarize", "translate", "explain"]

prompts.append("rewrite")
print(prompts[0])        # summarize
print(prompts[-1])       # rewrite
print(len(prompts))      # 4

prompts.remove("translate")
print(prompts)           # ['summarize', 'explain', 'rewrite']
print(prompts[1:3])      # ['explain', 'rewrite']

Positions start at 0, just like with strings. A negative position counts from the end, so -1 is the last item. Slices like [1:3] work the same way as on strings: from position 1 up to, but not including, position 3.

Some other things you'll use all the time:

numbers = [5, 2, 9, 1]

numbers.sort()               # sorts the list itself: [1, 2, 5, 9]
print(sorted(numbers))       # returns a new sorted list, leaves the original alone
print(9 in numbers)          # True

You can also put anything in a list, including other lists and dictionaries. That's how chat history is usually stored when you talk to a language model:

messages = [
    {"role": "user", "content": "Hi"},
    {"role": "assistant", "content": "Hello! How can I help?"},
]

A list of dictionaries. You'll see that exact shape over and over once we start building LLM apps.

Dictionaries: look things up by name

A dictionary stores pairs: a key and the value that goes with it. Instead of asking "what's at position 2?" you ask "what's the value for temperature?"

settings = {"model": "my-model", "temperature": 0.7, "max_tokens": 500}

print(settings["temperature"])     # 0.7

settings["max_tokens"] = 800       # change a value
settings["stream"] = True          # add a new pair

print("model" in settings)         # True

Loop over everything with .items():

for key, value in settings.items():
    print(key, value)

Here's a mistake almost every beginner makes. Asking for a key that isn't there with square brackets crashes your program with a KeyError. The safer way is .get(), which returns None instead, or a default you choose:

print(settings.get("top_p"))          # None
print(settings.get("top_p", 1.0))     # 1.0

Dictionaries remember the order you added things in. And keys have to be things that can't change, like strings, numbers, and tuples. A list can't be a key.

Tuples: a list you promise not to change

A tuple looks like a list but with round brackets, and once you make it, it's fixed.

point = (3, 4)
x, y = point        # unpacking: x is 3, y is 4

That second line is called unpacking, and it's one of the nicest things about Python. It's also how functions return more than one value:

def min_max(numbers):
    return min(numbers), max(numbers)

low, high = min_max([4, 9, 1])
print(low, high)     # 1 9

Under the hood, that function returns a tuple.

Use a tuple when the thing has a fixed shape and shouldn't be edited: a coordinate, an RGB color, a width and height. You'll bump into them again soon. The shape of an array in NumPy or a tensor in PyTorch, like (32, 128), is a tuple.

One quirk to remember: a tuple with a single item needs a trailing comma. (5,) is a tuple. (5) is just the number 5 in brackets.

Sets: unique things, no duplicates

A set keeps only one copy of each item, and it doesn't care about order.

words = ["a", "b", "a", "c", "b"]
unique = set(words)

print(unique)           # {'a', 'b', 'c'}  (the order can vary)
print("a" in unique)    # True

Sets are also great at comparing groups:

a = {1, 2, 3}
b = {3, 4}

print(a | b)    # {1, 2, 3, 4}   everything in either
print(a & b)    # {3}            only what's in both
print(a - b)    # {1, 2}         in a but not in b

A small trap: {} makes an empty dictionary, not an empty set. For an empty set, write set().

Which one should I use?

If you need...	Use a...
items in order that you'll add to or change	list
to look something up by a name or ID	dictionary
a small fixed group of values	tuple
unique items, or fast "is it in here?" checks	set

Why speed differs (and why it matters)

These containers don't just look different. They behave differently when they get big.

Say you have a list with a million numbers and you ask, "is 999,999 in here?" Python walks through the list one item at a time until it finds it. A million steps. A set or dictionary works differently. It uses a trick called hashing, which turns the item into a number that tells Python roughly where to look. It jumps almost straight to the right spot, no matter how big the set is.

Here's a quick way to see it for yourself:

import time

numbers_list = list(range(1_000_000))
numbers_set = set(numbers_list)

start = time.perf_counter()
999_999 in numbers_list
print("list:", time.perf_counter() - start)

start = time.perf_counter()
999_999 in numbers_set
print("set: ", time.perf_counter() - start)

On a normal computer, the list check takes around ten milliseconds and the set check takes a couple of microseconds. That's thousands of times faster. Your exact numbers will be different, but the gap will be big.

Programmers have a name for this idea: time complexity, usually written as Big-O. We'll cover it properly in Post 18, but here's the simple version.

Operation	List	Dictionary	Set
Get by position	Fast	n/a	n/a
Get by key	n/a	Fast	n/a
Is this item in here?	Slow (checks one by one)	Fast	Fast
Add to the end	Fast	Fast	Fast
Insert at the start	Slow	n/a	n/a

"Fast" means the time barely changes as the collection grows. "Slow" means it grows along with the number of items. (For dictionaries and sets, "fast" is true on average, which is good enough for now.)

Why should an AI engineer care? Imagine you're processing 100,000 documents and you want to skip ones you've already handled. If you keep the IDs in a list, each check can scan the whole list, which adds up to billions of comparisons by the end. If you keep them in a set, it's about 100,000 quick checks. Same result, wildly different wait.

A classic gotcha: copying a list

Run this and look at the output carefully:

a = [1, 2, 3]
b = a
b.append(4)

print(a)    # [1, 2, 3, 4]

You added to b, but a changed too. That's because b = a doesn't make a copy. It gives the same list a second name. Both names point to one list.

To make a real copy, use .copy():

b = a.copy()

That works for simple lists. If your list holds other lists or dictionaries, you'll later need copy.deepcopy, which we'll meet when it matters. For now, just remember that assigning doesn't copy.

Mini project: a word counter and vocabulary

When a language model reads text, one of the first things it needs is a vocabulary: the collection of unique pieces it knows about. Let's build a tiny version of that idea with the tools from this post.

Create word_counter.py:

text = """The cat sat on the mat. The dog sat on the log."""

words = text.lower().replace(".", "").split()

counts = {}
for word in words:
    counts[word] = counts.get(word, 0) + 1

# Sort the words by how often they appear, highest first
ranked_words = sorted(counts, key=counts.get, reverse=True)

for word in ranked_words[:5]:
    print(word, counts[word])

vocabulary = set(words)
print(f"Unique words: {len(vocabulary)}")

You should see:

the 4
sat 2
on 2
cat 1
mat 1
Unique words: 7

The heart of it is this line: counts[word] = counts.get(word, 0) + 1. It means "look up the current count for this word, use 0 if it isn't there yet, add one, and save it back." It's a pattern you'll use constantly.

In the sorting line, key=counts.get tells Python to sort the words by their counts instead of alphabetically. Don't worry if that feels odd. Post 6 explains why you can pass a function around like that.

Make it yours

Replace the sample text with a real text file, such as a chapter from a book.
Make a set of "stop words" like the, a, and on, and skip them when counting.
Print the ten most common words instead of five.
When you're done, look up collections.Counter in the Python docs. It does the counting loop for you. It's nice to meet a shortcut after you've done it the long way.

Practice

About 20 minutes of honest effort on each before you ask for help.

Reverse a list without using .reverse() or [::-1].
Write a function that takes a list of numbers and returns the smallest and largest as a tuple.
Remove duplicates from a list but keep the original order. (Hint: a set can remember what you've already seen.)
Swap the keys and values of a dictionary.
Given two lists of words, print the words they have in common.

As before, once you've finished, ask an AI tutor to review your code, not rewrite it.

What to take away

Lists keep things in order and can be changed.
Dictionaries let you look things up by key.
Tuples are fixed groups of values, and make returning several things easy.
Sets keep unique items and are very fast for "is it in here?" checks.
Picking the right container can turn a program that crawls into one that flies.
Writing b = a doesn't copy a list.

Previous: Post 4, Python Fundamentals

Next in the series: Post 6, Functions in Depth, where we go beyond the basics: scope, closures, flexible arguments, and passing functions around.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Python Fundamentals: The Basics You Need Before Anything Else

Pradeep Kumar — Wed, 21 Oct 2026 06:18:08 +0000

Almost everything in AI engineering is written in Python. The models, the libraries, the APIs, the tutorials. So this is where the coding starts.

This post is for people who are new to Python. If you already write loops and functions without looking things up, you can skip it. Here's a quick test. What does this print?

total = 0
for n in range(1, 6):
    if n % 2 == 0:
        total += n
print(total)

If you said 6 without running it, skip ahead to Post 6. If that code looked like a puzzle, stay. By the end of this post you'll read it easily.

Get Python running

You need two things: Python itself, and a place to write code.

Install a recent version of Python (3.11 or newer) from python.org.
Install VS Code as your editor. It's free and works well for this.
Open a terminal and check it worked:

python --version

If you see a version number, you're set. On some systems the command is python3 instead of python. Use whichever one works.

To run a file, save your code as hello.py and type:

python hello.py

You can also type python on its own to open a little playground where you test one line at a time. It's perfect for quick experiments.

Variables: names for things

A variable is a name that points to a value.

name = "Asha"
age = 29
height = 1.62
is_learning = True
nothing_yet = None

That's five variables, and you never had to say what type each one is. Python figures it out. That's one reason people find it easy to start with.

A few habits to pick up now:

Use snake_case for names: total_cost, not TotalCost or totalcost.
Make names say what the thing is. price is better than p.
Names are case sensitive. Age and age are different variables.

The basic types

You'll use these five constantly:

Type	Example	What it's for
int	42	whole numbers
float	3.14	numbers with decimals
str	"hello"	text
bool	True, False	yes or no
None	None	"nothing here yet"

Check the type of anything with type():

print(type(age))      # <class 'int'>
print(type(name))     # <class 'str'>

One quirk you should know about early, because it surprises everyone:

print(0.1 + 0.2)      # 0.30000000000000004

That's not a Python bug. Computers store decimals in a way that can't represent some numbers exactly, and you'll see the same thing in almost every language. It matters later when you compare numbers in AI code, so keep it in the back of your mind.

Working with text

Text, called a string, comes up in every AI project. Prompts are strings. Model replies are strings. So get comfortable with them.

The nicest way to put values inside text is an f-string. Put an f before the quotes and wrap variables in curly braces:

print(f"{name} is {age} years old")
# Asha is 29 years old

Strings also come with useful built-in tools:

message = "  Hello, World  "

print(message.strip())         # Hello, World
print(message.lower())         # "  hello, world  "
print(message.split(","))      # ['  Hello', ' World  ']
print(message.strip()[0:5])    # Hello

strip() removes extra spaces from the ends. split() cuts a string into pieces. And [0:5] is a slice, which means "from position 0 up to, but not including, position 5." Python counts from zero, which feels odd for about a week and then feels normal.

Making decisions with if

score = 72

if score >= 90:
    print("Excellent")
elif score >= 60:
    print("Pass")
else:
    print("Try again")

Two things to notice. First, the colon at the end of each condition line. Second, the indentation. In Python, the spaces at the start of a line aren't decoration. They tell Python which code belongs inside the if. Use four spaces, and your editor will usually do it for you when you press Tab.

Here's a handy fact. Python treats some values as "false" even when they aren't literally False: 0, an empty string "", None, and empty lists. Everything else counts as true. So you can write:

reply = ""

if not reply:
    print("The model returned nothing")

You'll write checks like that all the time when handling model output.

Repeating things with loops

A for loop runs code once for each item:

for number in range(1, 4):
    print(number)
# 1
# 2
# 3

range(1, 4) gives 1, 2, 3. It stops before the second number, the same way slices do.

You can loop over a list of things too:

for word in ["python", "is", "fun"]:
    print(word.upper())

A while loop keeps going as long as something stays true:

count = 3

while count > 0:
    print(count)
    count -= 1

Be careful with while. If nothing ever makes the condition false, the loop runs forever. If that happens, press Ctrl + C to stop it. It happens to everyone.

Two tools worth knowing: break leaves a loop early, and continue skips to the next round.

Now go back to the puzzle at the top. range(1, 6) gives 1 to 5, n % 2 == 0 checks if a number is even (% gives the remainder after dividing), and total += n means "add n to total." So it adds 2 and 4, and prints 6.

Functions: reusable chunks

A function packages some code under a name so you can use it again.

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

print(greet("Asha"))     # Hello, Asha!

def starts the function, name is its input (called a parameter), and return hands back the result.

You can give a parameter a default value:

def power(base, exponent=2):
    return base ** exponent

print(power(5))        # 25
print(power(5, 3))     # 125

We'll go much deeper into functions in Post 6. For now, the main idea is enough: write a function whenever you catch yourself copying the same code twice.

How Python actually runs your code

You don't need this to write programs, but it explains a lot later, so here's the short version.

When you run python hello.py, Python reads your file from top to bottom. Behind the scenes it first turns your code into a simpler set of instructions called bytecode, and then a program called the Python interpreter carries out those instructions one at a time.

That makes Python quick to write and easy to debug, but slower than languages like C when you're doing raw number crunching in loops.

So why is Python the language of AI? Because the heavy work doesn't happen in Python. Libraries like NumPy and PyTorch do the heavy math in fast C, C++, and GPU code. Your Python code just tells them what to do. It's a bit like a conductor, who doesn't play every instrument but makes the orchestra work together. You get the easy language and the speed.

Reading error messages

You'll see a lot of errors. That's normal and it never fully goes away, even for experienced people. The trick is to read them properly.

age = 29
print("Age: " + age)

TypeError: can only concatenate str (not "int") to str

Read the last line first. It tells you what went wrong: you tried to join text and a number. Then look at the line number above it to see where. The fix:

print(f"Age: {age}")

A few errors you'll meet early:

NameError: you used a name that doesn't exist, usually a typo.
TypeError: you mixed types that don't go together.
IndentationError: your spacing is off.
SyntaxError: something is missing, often a colon or a closing bracket.

We'll cover debugging properly in Post 11.

Mini project: a token and cost estimator

Language models don't read words. They read tokens, which are small pieces of text. And you're charged by the token when you use most model APIs. So estimating tokens is useful from day one.

A rough rule of thumb for English is about 4 characters per token. It's not exact, but it's close enough to get a feel for size and cost.

Create a file called token_estimator.py:

text = input("Paste some text: ")

characters = len(text)
words = len(text.split())

# Rough rule of thumb: about 4 characters per token in English
estimated_tokens = characters / 4

# Made-up price. Check your provider for real numbers.
price_per_million_tokens = 3.00
estimated_cost = estimated_tokens / 1_000_000 * price_per_million_tokens

print(f"Characters: {characters}")
print(f"Words: {words}")
print(f"Estimated tokens: {estimated_tokens:.0f}")
print(f"Estimated cost: ${estimated_cost:.6f}")

Run it with python token_estimator.py, paste in a paragraph, and see what comes out.

A few new bits in there: len() counts how many characters or items something has, input() asks the user to type something, and :.0f inside an f-string means "show this number with no decimals."

The price is invented on purpose. Real prices change often and differ between models, so never trust a number from a blog post. Look it up for the one you're using.

Make it yours

Change the project so that it isn't just my example anymore:

Print a warning if the estimate goes above 1,000 tokens.
Read the text from a file instead of asking you to paste it.
Wrap it in a while loop so you can check many texts, and stop when you type quit.

Practice

Try these without looking anything up. Aim for about 20 minutes of honest effort before you ask for help.

Ask for the user's name and print a greeting.
Convert a temperature from Celsius to Fahrenheit.
Count the vowels in a sentence.
Print the numbers from 1 to 20, but print "Fizz" for multiples of 3.
Write a function is_even(n) that returns True or False.

When you finish, paste your solution into an AI tutor and ask it to review the code, not rewrite it. That's the habit from Post 3, and it works.

What to take away

Variables are names for values, and Python figures out the type for you.
Strings, numbers, booleans, and None cover most of what you'll use early on.
Indentation is part of the syntax.
Functions let you reuse code instead of copying it.
Python is mostly the glue. The fast work happens in libraries underneath.
Read error messages from the last line up.

Previous: Post 3, How to Learn AI Faster

Next in the series: Post 5, Built-in Data Structures, where we learn lists, dictionaries, sets, and tuples, and how fast each one is.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

How to Learn AI Faster (Without Getting Stuck in Tutorial Hell)

Pradeep Kumar — Mon, 19 Oct 2026 06:53:04 +0000

Most people don't give up on AI because it's too hard. They give up because they got stuck in something I'll call tutorial hell, and they never noticed.

Here's how it goes. You watch a six-hour course. Everything makes sense while the instructor types. You nod along, you feel smart, you finish the last video. Then you open a blank file and can't write a single line.

If that sounds familiar, good news: it's fixable, and this post is how.

Why tutorial hell happens

Watching someone do something and doing it yourself use different parts of your brain. When you watch, you recognize. When you build, you recall, and recall is the thing you need on the job. Recognizing the answer is easy. Producing it from nothing is hard, and that hard feeling is exactly what makes you learn.

So the rule for this whole series is simple: if it feels a little uncomfortable, it's working.

1. Build something every week

After every post, make something small that isn't the example in the post. Change one thing about it.

The post builds a token counter? You build one that also tells you the cost. The post calls an API to summarize text? You point it at your own notes. The goal is not a great project. The goal is making decisions that nobody made for you.

Keep it small enough to finish in a few hours. A finished ugly project beats a beautiful one that's never done.

2. Type the code, don't paste it

When you copy and paste, your hands move but your brain checks out. Type it, even when it feels slow. You'll make typos, and fixing those typos teaches you more than you'd think.

And when you hit a bug, give yourself about 20 minutes to fight it before asking for help. That struggle is where the learning lives. After 20 minutes with no progress, ask. Don't suffer for hours.

3. Use AI as a tutor, not a ghostwriter

This one matters a lot, since you're learning to build AI and you also have AI to help you learn. It's an incredible tutor. It's also an easy way to fool yourself into thinking you learned something.

Good ways to use it:

"Quiz me on Python generators, one question at a time. Don't give me the answer until I've tried."
"Here's my code. Don't fix it. Just tell me which part to look at."
"Explain this like I'm new to it. Then give me one harder follow-up question."
"Here's how I understand it. Where am I wrong?"

Not so good ways:

Asking it to write the whole project, then pasting the result.
Accepting an answer you don't understand, just because it sounds confident.

Two more things to keep in mind. First, AI can be confidently wrong. This happens most with new library versions and fast-changing tools, which is a lot of what we'll use. So always run the code, and check the official docs when something matters. Second, here's a simple test of whether you learned or just copied: tomorrow, can you rebuild it with nothing open? If yes, you learned it. If not, go back.

4. Explain it back

After you learn something, try to explain it in your own words, out loud or in writing, as if to a friend who knows nothing about it. Anywhere you stumble is a gap in your understanding, and now you know where to look.

It sounds too simple to be useful. It's one of the most reliable tricks there is.

5. Build in public

This sounds scarier than it is. It doesn't mean going viral. It means leaving a trail.

Push your code to GitHub as you go.
Write one short note a week about what you learned or what broke.
Share it somewhere: a blog, LinkedIn, a dev community, even a private repo at first.

You don't need an audience. Having anyone in mind, even an imaginary reader, makes you finish things and explain them clearly. And down the line, that trail becomes your portfolio. A hiring manager scrolling through a year of honest weekly notes learns more about you than any resume could show them.

A great post doesn't have to be impressive. "Week 6: I wrote my first async script, it broke in three different ways, here's what I learned" is a perfectly good post.

6. Keep a bug diary

Every time something breaks, write down three lines: what happened, what caused it, how you fixed it. In a few months you'll have a personal handbook of the exact mistakes you tend to make. You'll also notice you're making fewer of them, which is a nice thing to see on paper.

7. Review a little, often

Memory fades. That's normal, not a sign you're bad at this. Once a week, spend 15 minutes looking back at something from a few weeks ago. Re-read your notes, redo a small exercise, or have an AI tutor quiz you. Seeing something again right when you're about to forget it is what makes it stick.

Common mistakes

Collecting courses. Bookmarking five more courses feels like progress. It isn't. Pick one resource per topic and finish it.
Switching tools constantly. A new framework appears every week. Ignore most of them while you learn the basics.
Waiting until you feel ready. You won't feel ready. Start before you do.
Comparing yourself to people online. You're seeing their best moments, at their current level, after years of work you can't see.
Avoiding the math completely. It's less scary than it looks, and we'll take it slowly in Phase 2.
Marathon weekends followed by silence. Regular beats intense.

What "faster" really means

It doesn't mean cramming. It means wasting less time: less time watching without doing, less time stuck alone, less time re-learning things you forgot. A steady five hours a week beats twenty hours once a month, every time.

Try this today (20 minutes)

Create a GitHub account if you don't have one.
Make a new repository called ai-engineer-journey.
Add a README with your start date, your goal, and the weekly study slots you picked in the last post.
Make your first commit.

You've now started building in public, and you did it before writing a single line of code. The streak starts today.

Previous: Post 2, The 12-Month Roadmap

Next in the series: Post 4, Python Fundamentals, where we start writing real code.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

The 12-Month Roadmap: Zero to AI Engineer

Pradeep Kumar — Mon, 12 Oct 2026 06:18:52 +0000

A year sounds like plenty of time until you look at 79 posts and wonder how any of it fits. This post is the plan. Read it once now, then come back whenever you feel lost.

Read this first

The schedule below assumes two things:

You can give it about 8 to 10 hours a week.
You're starting with little or no coding experience.

If either is different for you, the plan still works. It just stretches or shrinks. Some people will finish in nine months, others in eighteen, and both are fine.

Also, this is a plan, not a promise. Nobody can guarantee a job at the end of twelve months, because it depends on the market, your background, and how much you build. What I can say is that if you follow this and finish the projects, you'll have real skills and real proof of them.

The year in one table

Months	Weeks	Phase	Posts	What you'll have made
1 to 3	1 to 14	Orientation + Programming in Depth	1 to 30	A CLI tool, a tested REST API, and a Python package on PyPI
4	15 to 18	Math & Data for AI	31 to 37	A data analysis notebook on GitHub
5	19 to 22	Machine Learning & Deep Learning	38 to 42	A trained image or text classifier
6	23 to 26	Transformers & LLMs Under the Hood	43 to 48	A tiny GPT you built yourself
7 to 8	27 to 34	Building with LLMs	49 to 59	A deployed RAG or agent app with a public demo
9	35 to 39	Evaluation, Safety, and Customizing Models	60 to 67	An eval suite and a fine-tuned open model
10	40 to 43	Production & Scale	68 to 71	Your app running in the cloud with tracing, caching, and cost limits
11 to 12	44 to 52	Career & Becoming Top-Tier	72 to 79	A portfolio, a resume, interview practice, and real applications

Month by month

Months 1 to 3: Learn to code properly. This is the longest phase and the least glamorous. You'll learn Python well, the computer science that actually matters, and the daily tools like Git and Docker. It feels slow. Stick with it anyway, because every later phase leans on it. People who rush through this part tend to hit a wall around PyTorch and async code.

Month 4: Math and data. Vectors, gradients, probability, and working with real messy data. We'll keep it intuitive. You won't be proving theorems.

Month 5: Machine learning. Classic ML first, then neural networks from scratch, then PyTorch. This is where AI stops feeling like magic.

Month 6: Inside the transformer. Tokenizers, attention, and building a small GPT. You won't build a model that rivals the big ones, but you'll understand why they work the way they do, and that understanding pays off every time something breaks later.

Months 7 and 8: Build with LLMs. The core of the job. API calls, tool use, search over documents, agents, MCP, voice and images. You finish with a deployed app that someone else can try.

Month 9: Test it and make it yours. How to measure whether your app is good, how to keep it safe, and when (and when not) to fine-tune a model.

Month 10: Ship it for real. Speed, cost, GPUs, cloud, and keeping things running.

Months 11 and 12: Get hired. Portfolio, resume, interviews, open source, and choosing a direction. You should be applying by the middle of month 11, not waiting until you feel "ready."

A weekly rhythm that works

Pick a rhythm and stick to it. Here's one that fits in roughly 9 hours:

Early week (about 3 hours): read the post and code along. Type everything yourself.
Late week (about 5 hours): build the mini-project, or change the example into something of your own.
Weekend (about 1 hour): write down what you learned, push your code to GitHub, and skim your notes from last week.

Short, regular sessions beat one giant weekend. Five hours spread across the week will teach you more than fifteen hours crammed into one day, mostly because your brain needs sleep to keep things.

Where should you start? Pick your path

Not everyone needs all 79 posts.

If you are...	Do this
A complete beginner	Read posts 1 to 79 in order.
Already able to code	Read posts 1 to 3, skim posts 10, 13, and 14 (types, testing, concurrency), then jump to post 31. You'll finish in about nine months, or sooner.
Already know ML	Read posts 1 to 3, skim posts 11 and 14, then jump to post 43 or 49. Closer to six months.

If you're not sure which one you are, here's a quick test. Can you write a small Python program that reads a file, calls a web API, and handles errors, without copying it from somewhere? If yes, you can code. If not, start at the beginning. There's no shame in either answer.

How to know you're on track

Check yourself at these points:

End of month 3: you can write and test a small Python program from a blank file, without copying.
End of month 6: you can explain, in plain words, how a model produces the next word.
End of month 9: you have a live app, and numbers that show how well it works.
End of month 12: you've applied for roles, and you have a portfolio you're proud of.

Miss one by a few weeks? Totally normal. Shift the schedule, don't quit.

Four rules for finishing

Don't skip the projects. Reading feels like progress. Building is progress.
If you're stuck for two hours, ask someone. A forum, a friend, an AI tutor (the next post is about using one well). Hours of silent struggle teach less than people think.
When you fall behind, move the dates. Don't throw out the plan.
Don't chase every new tool. New models and libraries will appear every month while you're doing this. Most of them won't matter for your first job. The ideas underneath will.

Try this today (15 minutes)

Decide your start date. Tomorrow is fine.
Block out your weekly study slots in your calendar, the actual hours, with real times.
Write down which path you're taking: beginner, can code, or knows ML.

That's it. A plan with a date and calendar slots beats a plan that lives in your head.

Previous: Post 1, What Is an AI Engineer in 2026?

Next in the series: Post 3, How to Learn AI Faster, including how to use AI as a tutor without letting it do your homework.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

What Is an AI Engineer in 2026?

Pradeep Kumar — Sun, 11 Oct 2026 07:05:20 +0000

Ask five people what an AI engineer does and you'll get five different answers. Part of the reason is that the job is new. The other part is that companies stick the title on roles that have almost nothing in common.

So before you spend a year learning anything, let's figure out what this job really is, what it isn't, and whether it's the one you want.

The short version

An AI engineer builds real products using AI models that already exist.

That's the whole idea. A handful of big labs and open-source groups train the giant models. AI engineers take those models and turn them into things people actually use. A support bot that answers questions correctly. A tool that reads contracts and flags the risky parts. A coding assistant. A voice agent that books appointments.

The work sits between software engineering and machine learning, and it leans a lot closer to software engineering than most beginners expect. If you can build a solid app and you understand how these models behave, you're already most of the way there.

The restaurant comparison

The easiest way I know to explain the different roles is a restaurant.

The research scientist invents new ways of cooking. New techniques, new ingredients. They write papers about it.
The ML engineer builds the kitchen that can produce that new ingredient in huge amounts, every day, without it going wrong. Training pipelines, GPUs, deployment.
The data scientist studies the orders. Which dishes sell, why customers stop coming back, whether the new menu actually helped.
The AI engineer is the chef. They take the best ingredients available and cook dishes people want to eat, then make sure those dishes come out right every single night.

In real life the lines blur. At a small startup one person might do three of these jobs before lunch. But it gives you a map to start with.

The same thing, in a table

Role	The question they ask	Typical work	Common tools
Research scientist	Can we make models fundamentally better?	Experiments, papers, new methods	PyTorch or JAX, big GPU clusters, heavy math
ML engineer	How do we train and run models reliably at scale?	Training pipelines, deployment, monitoring	PyTorch, Kubernetes, Spark, MLOps tools
Data scientist	What is the data telling us?	Analysis, experiments, forecasting, dashboards	SQL, Python, statistics, notebooks
AI engineer	How do we turn a model into a product that works?	LLM apps, search over documents, agents, testing, shipping	Python or TypeScript, model APIs, vector search, eval tools

What an AI engineer does in a normal week

Here's a realistic list. Not every week has all of these, but most weeks have most of them.

Talks with a user or teammate about a problem worth solving. Sometimes the answer is "you don't need AI for this," and saying so is part of the job.
Writes code that sends a request to a model, gives it the right information, and handles whatever comes back.
Connects the model to real stuff: documents, databases, APIs, internal tools.
Builds tests (people call them evals) to find out whether the thing really works. "It looked good in the demo" is not a measurement.
Chases down weird failures. The model invented a refund policy that doesn't exist. A user pasted in something strange. A tool call timed out halfway through.
Keeps an eye on cost and speed. A feature that costs too much per request, or takes forty seconds to answer, won't survive for long.
Ships it, then watches how people actually use it. This part usually teaches you the most.

Notice how little of that list is math. There's some, and we'll cover it. But most of the job is regular engineering with one unpredictable piece sitting in the middle.

What you need to know

An honest skills list:

Solid programming. Mostly Python, and more and more TypeScript.
Web basics. APIs, databases, async code.
Enough ML to understand the models. Not to invent them, just to understand why they act the way they do and why they sometimes fail.
A testing mindset. You'll be checking outputs that change from run to run, which is harder than it sounds.
Clear communication. You'll often explain to non-technical people why the model did something odd.
Taste. Knowing when an answer is good enough and when it isn't.

And what you don't need to get started: a PhD, a master's degree, a GPU cluster, or math beyond the basics we'll cover together in Phase 2.

Is this job for you?

It's probably a good fit if you:

like building things and watching people use them
can live with messy, imperfect results (the same question can get a different answer tomorrow)
enjoy debugging, even when the bug is "the model just decided to do something else"

It might not be if you:

want to invent new model architectures or prove things mathematically. That's the research path, and it's a great one, just a different one.
really dislike ambiguity. AI products are never 100% correct, and a big part of the work is deciding how wrong is too wrong.

A warning about job titles

Titles are a mess. Don't trust them, read the job description.

If it talks about building, shipping, LLM apps, RAG, agents, or evals, that's AI engineering. If it talks about pretraining, distributed training, or novel architectures, that's ML or research, and it usually wants more math and often a graduate degree.

What this series will do

This is a 79-post series that takes you from zero to a working AI engineer. We start with programming in depth, because nearly everything else depends on it. Then math and data, classic machine learning, how transformers and LLMs work inside, building real LLM apps, testing them, customizing models, shipping to production, and finally the career side: portfolio, interviews, and getting hired.

You don't need to read it all in order. If you already code, the next post shows you where to jump in.

Try this today (10 minutes)

Open three job postings with "AI Engineer" in the title. Copy every skill and tool they mention into a note. Then circle the ones that appear in all three.

Keep that note. At the end of the series we'll come back to it and see how much of it you can now tick off.

Next in the series: Post 2, The 12-Month Roadmap, the whole plan with a week-by-week schedule.

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Margaret Hamilton, Who Helped Put Humans on the Moon, Has Died

Pradeep Kumar — Sat, 10 Oct 2026 09:07:51 +0000

The alarm that didn't stop the landing

It is July 1969. The Apollo 11 lunar module is minutes from touching down, and the onboard computer starts flashing an alarm: 1202. The machine is overloaded, thanks to a problem with a hardware switch, and nobody is sure it can handle the most delicate maneuver of the mission.

In another era, that might have been the end of the landing. It wasn't, because years earlier a team of MIT software engineers had built the computer to expect trouble. Its software was priority-driven: when it was swamped, it dropped the less important jobs and held on to the ones that mattered. Mission control understood what the alarm meant, trusted the software, and told the crew to keep going. Two people walked on the moon.

The woman who led that software effort was Margaret Hamilton. She died on September 30, 2026, at the age of 90, MIT announced this week.

From weather forecasts to the moon

Hamilton was born in Paoli, Indiana, in 1936. She studied mathematics, finishing a degree at Earlham College in 1958 with a minor in philosophy, and moved to Boston the following year when her husband began law school. She expected the job at MIT to be temporary. It was a position in the meteorology department, writing weather-prediction software for Edward Lorenz, whose later work on chaos theory her programming helped inform.

From there she moved to MIT Lincoln Laboratory to work on SAGE, the country's first air defense system. That is where she grew fascinated by something almost no one was talking about yet: how to make software reliable.

In 1965, just as she was planning graduate school, her husband spotted a newspaper ad. MIT's Instrumentation Lab needed people to write the flight software that would send a man to the moon. Hamilton applied and became the first programmer hired for Apollo at MIT. By 1968 she was an assistant director running the team behind the Command and Service Module software, part of an effort that involved more than 400 people.

The error her daughter found

One of the most beloved stories about Hamilton's career starts with her four-year-old daughter, Lauren, playing in the command module simulator at the lab. Lauren accidentally launched a pre-launch program in the middle of a simulated flight, and the simulator crashed.

Hamilton saw the risk right away. She wrote a warning into the documentation and proposed a software safeguard, but she was overruled: astronauts were far too well trained to make that mistake. Then, on Apollo 8 in 1968, Jim Lovell did exactly that, wiping out navigation data in flight. Hamilton's team got it sorted out, and her safeguard went into the software.

The lesson is one engineers still carry: build systems that anticipate mistakes and recover from them, rather than assuming people and machines will always behave. Today we call it defensive programming.

Giving software its due

Hamilton didn't stop at Apollo. When the Instrumentation Lab became the independent Draper Laboratory, she kept going, founding Higher Order Software in 1976 and, about ten years later, Hamilton Technologies. Both were built around her conviction that errors should be prevented by design, not caught after the fact. Her company's Universal Systems Language grew out of that philosophy.

She also fought for the idea that software deserved to be treated as a real engineering discipline. By her own account, when she began using the phrase "software engineering," people thought it was a joke. Over a career that produced more than 130 publications, the joke turned into an industry.

The recognition eventually arrived:

NASA's Exceptional Space Act Award (2003)
The Presidential Medal of Freedom, presented by President Obama (2016)
Computer History Museum Fellow (2017)
The Intrepid Lifetime Achievement Award (2019)
Induction into the National Aviation Hall of Fame (2022)

An icon for a new generation

For many people, Hamilton became familiar through a single photograph: a young woman standing beside a stack of Apollo code printouts about as tall as she is. As that image spread online, she became a symbol for women in science and technology. In 2015 the Apollo software was uploaded in full to GitHub, and in 2017 she became a Lego minifigure in the Women of NASA set designed by MIT's Maia Weinstock.

Looking back on her Apollo years, Hamilton said there was "no choice but to be pioneers." She was right about the pioneering, though the choice she made was her own: to take a field everyone treated as a mystery and a black box, and insist that it be done carefully, honestly, and with respect for the people who would depend on it.

Every time software quietly handles a failure so you never notice, there's a bit of her work in it.

Hamilton is survived by her daughter, Lauren Hamilton, her son-in-law, two grandsons, four great-grandchildren, and her siblings. A memorial service is planned for the spring in Cambridge, Massachusetts.

Source: MIT News, "Margaret Hamilton, computing pioneer who led software development for the Apollo program, dies at 90"

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

Google Playground: Turn a Game Idea into a Playable Game, Without Writing Code

Pradeep Kumar — Fri, 09 Oct 2026 15:45:49 +0000

Most people have a game idea sitting somewhere: a trivia night for friends, a tower defense with a twist, a silly racing concept from a notebook margin. Few of them get built, because making a game usually means learning an engine, a language, and a pile of tooling first.

Google Labs' new experiment, Playground, tries to remove that barrier. Launched on October 7, 2026, it lets you create playable games in minutes just by describing them in plain language.

What Is Playground?

Playground is a browser-based gaming platform from Google Labs, built around one promise: custom games with no coding required. You work in a chat-style interface, describe what you want, and the game takes shape. Google's tagline is "If you can think it, you can play it." Under the hood, Playground combines Google's Gemini, Nano Banana, and Lyria models with a custom system designed for game creation.

Google is aiming it at two groups: hobbyists with a backlog of game ideas, and people who are simply curious about what AI can do.

How It Works: Create, Play, Share

Create. You start in a chat window, either from a genre template (Google names Trivia, Tower Defense, and Racing) or from a blank slate. You steer the game with text prompts, and the rules are yours to set. TechCrunch also reports that you can upload your own visuals and have Playground turn them into game assets that fit the game's art style.

Play. You can test the game immediately, in the browser, on a phone or a laptop. If the difficulty feels off or a mechanic falls flat, you ask for a change and try again. That play-tweak-play loop is the heart of the experience.

Share. A game can stay private, go to friends by link, or be published to Playground's Explore gallery for anyone to play. You can keep modifying it after it's published. Published games go through safety screening against Google's community guidelines, and Playground supports leaderboards and multiplayer for select genres, so not every game will have them.

What Google Is Showcasing

Google's launch page features a gallery of example games. A selection:

Snooze Jump, a dream-themed cloud-climbing platformer with a relaxed Normal Mode and a tense Speedrun Mode.
Truth Ninja, a fast-paced game that mixes reactions with trivia as you defend a temple.
Polygon Pazer, a retro 3D tank battle with Mode-7-style ground, played as a tactical 3v3 team deathmatch.
Pitfalls, a physics-based game about stacking skyscrapers.
Octo Pop, a pixel-art arcade shooter set in a bioluminescent ocean trench, starring an octopus named Ollie.
Foosball Shootout, a hypercasual foosball game.

The range is the point: a platformer, a trivia game, an arcade shooter, a physics stacker, and a sports game, each with its own look and tone. Several descriptions also mention specific design choices, like Snooze Jump's two difficulty modes, which suggests creators are shaping mechanics rather than only picking templates.

Why This Matters

Game creation has always had a steep entry cost. Playground starts from the idea instead and lets the tooling catch up. That changes who gets to be a game designer: someone with a clever rule set or a funny theme, but no programming background, can now prototype it.

The process is also conversational. You can tweak a game's physics, rewrite its rules, change its characters, or overhaul its environment just by asking, then test the result right away. That doesn't replace the whole development process, but it takes over much of the initial coding and iteration work. Cheap experiments tend to produce surprising ideas, and this makes experiments very cheap.

Try It: A Starter Prompt

If you have access, start specific. Here's an illustrative prompt (my own example, not one from Google):

A cozy tower defense game where garden gnomes defend a vegetable patch from crows. Three gnome types, a watercolor art style, and a boss crow every fifth wave.

From there, change one thing at a time: slower crows, a new gnome, a harder boss. Test after each change so you can tell what helped.

Things to Keep in Mind

It's an experiment. It lives under Google Labs, so expect it to change and expect some rough edges.
Access is limited. Playground launched in the U.S. for users 18 and older, and Google plans to expand to more countries. Browsing and playing games is free. Creation access is tiered by Google One membership, with free users getting a limited weekly allowance and subscribers getting higher limits.
Results will vary. Describing a game gets you a playable starting point quickly, but a polished one will likely take several rounds of refinement.

The Bottom Line

Playground won't replace traditional game development, but it doesn't need to. Its value is in shrinking the distance between "I have an idea" and "I can play it" from a long learning curve to a few minutes of chatting. If you've ever had a game concept you never built, it's worth a look as soon as it's available where you are.

Try it at playground.google.

Sources

Google, Introducing Playground: Create and play custom games
TechCrunch, Google experiments with an AI-powered gaming platform
Google Labs: Playground

Published via ZyVOP — Write once in Markdown, auto-backup to GitHub, and syndicate to Dev.to, Medium & Hashnode in 1 click.

DEV Community: Pradeep Kumar

Testing with pytest: Fixtures, Fake Models, and Properties

Tests are not evals

Your first test

When a test fails

What makes a good test

Testing that an error is raised

Many cases, one test: parametrize

Fixtures: reusable setup

monkeypatch: changing things temporarily

Testing code that calls a model

When you can't pass a fake in: mock and patch

Don't overdo it

Property-based testing: let the computer find the weird inputs

Running tests well

Mini project: a test suite for textkit

Make it yours

Practice

What to take away

Packaging & Environments: Modules, Virtual Environments, and pyproject.toml

Modules: a file is a module

The __name__ trick

A mistake that confuses everyone once

Packages: a folder of modules

The problem environments solve

Virtual environments: one box per project

uv: the modern way

pyproject.toml: the project's ID card

Versions and lock files

Another kind of environment: environment variables

Mini project: your first package

Make it yours

Practice

What to take away

Decorators & Context Managers: The @ and with You Keep Seeing

The problem decorators solve

Building a decorator by hand

A small fix: functools.wraps

Decorators that take settings

Decorators that register instead of wrap

A few built-in decorators worth knowing

Context managers: cleaning up after yourself

How with works

The easy way: @contextmanager

Where you'll see these in AI work

Mini project: a small toolkit

Make it yours

Practice

What to take away

Iterators, Generators & Comprehensions: How Python Handles Streams of Data

Comprehensions: loops in one line

What a for loop really does

Generators: functions that pause

Why lazy matters: memory

Reading big files, one line at a time

Streaming model output

Batching: a pattern you'll use constantly

Mini project: a lazy text pipeline

Make it yours

Practice

What to take away

Functions in Depth: Scope, Closures, and Passing Functions Around

A quick recap, plus a trap

*args and **kwargs: any number of arguments

Scope: where a variable lives

Functions are just values

Higher-order functions

Lambdas: tiny throwaway functions

Closures: functions that remember

Habits for writing good functions

Mini project: a retry helper

Make it yours

Practice

What to take away

Built-in Data Structures: Lists, Dicts, Sets, and Tuples

Lists: an ordered collection you can change

Dictionaries: look things up by name

Tuples: a list you promise not to change

Sets: unique things, no duplicates

Which one should I use?

The `name` trick

How `with` works

The easy way: `@contextmanager`

`*args` and `**kwargs`: any number of arguments