ArjanCodes/examples is a video companion repository, not a library

What the repository is for

The description is one line: all the code examples used in the videos. The homepage is the YouTube channel rather than a documentation site, which tells you the delivery mechanism. The video is the lesson, and this repository is the code that goes with it.

The stated workflow is specific. Each video description contains a link to the code, and a regular watcher can simply clone the repository and check out the code for the latest video. The main branch will always contain the latest code.

That last sentence is the whole design constraint, and it explains most of what follows. A repository whose default branch is defined as always moving is not something you version, pin or depend on. It is something you read.

The repository topics are design patterns, Python, software and tutorials, so the subject matter is software design rather than a particular framework or library. If you are looking for a worked example of a pattern, this is where the author has written one, with whatever supporting code the explanation needed.

It is also worth noting what this repository is not. There is no package to install, no API, no library surface and no compatibility promise. The MIT licence covers reuse of the example code, and the README invites issues and pull requests to improve it.

Year directories, and what they imply

The repository root is a list of years: `2022/`, `2023/`, `2024/`, `2025/` and `2026/`, alongside `README.md`, `LICENSE`, a `.pylintrc`, a `.vscode/` directory, a `.github/` directory and a `.gitignore`.

The year layout is the only navigation available. There is no index of lessons, no table mapping videos to directories, and no tags. If you arrive knowing which video you want, the year is a fast filter. If you arrive wanting a topic, you are browsing five years of directories by hand.

The distribution across those years also shows what kind of project this is. A directory for 2026 exists alongside one for 2022, which means content is still being added and nothing older has been retired. For a teaching repository that is the right call, since older examples still correspond to videos people watch.

The absence of releases follows from the same design. The repository has no GitHub releases, and the README does not describe a tagging scheme. So if you want to reproduce what a video showed two years ago, the year directories are the closest thing to a stable reference, and even those are on a branch that is always moving.

One environment per example, and why that matters

The installation section is three sentences and one instruction that carries the real guidance: ensure you have the necessary dependencies installed for each example, and note that each example should have at least a `pyproject.toml` in which you can use poetry to create a virtual environment for that specific example.

That convention is not a detail. Video examples are written to demonstrate one idea at a time, and demonstrating an idea often means using a specific version of a library, or a tool that conflicts with the one used in the previous lesson. If every example installed into one shared environment, the repository would stop working the first time two lessons disagreed about a dependency.

So the expected workflow is per-example isolation:

git clone https://github.com/arjancodes/examples.git
cd examples

and then, inside the directory for the lesson you are following, create a virtual environment with poetry. The word at least in the README signals that this is a convention rather than an enforced guarantee, so the first thing to check in any given directory is whether the pyproject.toml is there.

The `.pylintrc` at the root is a related signal. Linting configuration shared across every example implies the code is meant to meet a consistent standard, which is what you want if you are going to read it as a model for your own code rather than only to run it.

Two committed files that explain what the examples do

There are two files at the repository root that are worth a second look because they are artifacts rather than documentation: `database.db` and `warnings.txt`.

A committed SQLite database means at least one example writes to a database file and leaves it in the working tree. A committed `warnings.txt` means at least one example produces warnings that the author captured to a file. Both are consistent with examples that demonstrate persistence or with a debugger session that needed the state written somewhere visible.

Neither is documented in the README, so nobody reading the repository will be told that running certain examples will modify files at the root of the clone. If you check out this repository and then want to work on it, the first thing worth doing is looking at what those two files contain before overwriting anything.

The `.gitignore` is present but evidently not covering them, which is common in a repository that accretes files as videos are recorded rather than as a curated project.

One more small inconsistency: the repository's primary language is recorded as HTML, which does not match a repository described as Python examples with design patterns topics. That is metadata rather than content, but it is another reason to look at the tree rather than trust the repository summary.

Who maintains it and what the project status is

Two people are named in the README. Arjan Egges is the project maintainer, and Andreas Bergman is listed as developer and educational specialist.

The educational framing in that second title matches how the repository presents itself, and it explains the structure: the code is written to be watched and read, which is why each example is small enough to understand in one sitting and isolated enough to run without setup archaeology.

Links go out to a YouTube channel, an X account and a LinkedIn company page. The MIT licence is declared both as a badge and in the README.

The last push was on 2026-10-14 and the repository is not archived, so new videos continue to land new examples. There are no GitHub releases, which is the correct choice for this kind of repository and also the reason there is nothing to pin.

So the realistic evaluation is short. This is a well-organised, actively extended companion to a video series, with per-example dependency isolation and consistent lint configuration. It is a good place to look for a worked design pattern example in Python, and it is the wrong thing to build on top of.

Editorial conclusion

Adopt this repository as a reference while working through a video from the series, since each example is self-contained and the year directories make it easy to find the one matching a lesson. Do not add it as a dependency of your own project, because there is no package, no release and no stability promise, and the default branch is described as always containing the latest code. Verify first which year directory matches the video you are following, create a per-example environment with poetry rather than installing everything into one, and read the licence before lifting any code into work of your own.

Frequently asked questions

Official sources

1. ArjanCodes/examples on GitHub
2. Issues
3. License: MIT
4. Project website
5. README