WTF Python keeps its runnable code in a snippets directory, and its last release tag is from 2019

The examples are files in snippets/, and the README is generated

The first thing to understand is that this is a repository, not a library. There is no installation step and nothing to add to a requirements file. The runnable code sits in a directory called snippets/, the documentation is a single README.md, and the supporting material lives in images/ for the diagrams and translations/ for the language versions. Two other directories are worth naming because their purpose is not obvious. There is one called irrelevant/, which holds a notebook named wtf.ipynb, and there is a single Python file at the repository root called mixed_tabs_and_spaces.py, which exists as a demonstration rather than as part of a build. The tooling around the README is conventional: a pre-commit configuration, a markdownlint configuration, a noxfile for task automation, and a Travis configuration. The table of contents in the README is not written by hand, it is generated with a single command:

markdown-toc -i README.md --maxdepth 3

The depth of three is why every entry nests exactly three levels, section then example, and no deeper.

Asterisks mark new examples, and the last major revision was 2019

The maintenance picture needs two dates read together. The most recent tagged releases are v3.0.0, dated 21 December 2019, and v2.0.0, dated 22 January 2018, which is the entire release history. The last push to the master branch, however, is dated 13 January 2026, and the repository is not archived, so work has continued for years after the last major tag. The consequence shows up in how the README itself is organised. Examples introduced in the latest major revision are marked with an asterisk in the headings, and the project tells returning readers to check the releases page for what changed. Since that latest major revision is the 2019 tag, the asterisks have been pointing at the same set of examples ever since, and anything added since then is unversioned. Reading the asterisks as a recency signal will mislead you.

Five sections, ordered from strain your brain to miscellaneous

The examples are not a flat list, they are graded, and the section titles set expectations before you read a line. The first is called Strain your brain, and it is the largest, holding the classics such as how not to use the is operator, the surprising comma in a tuple, what is wrong with booleans, the difference between mutating an immutable, the disappearing variable from outer scope, and the limit on integer to string conversion. The second is Slippery Slopes, which is the most useful section for working code: modifying a dictionary while iterating over it, deleting a list item while iterating, the default mutable argument trap, name resolution ignoring class scope, and name resolution that leaks loop variables out of their scope. The third is The Hidden treasures, covering the slice assignment trick, goto by exception, brace indexing on lists, the fluent style, ellipsis, and mangling. The fourth is Appearances are deceptive, and the fifth is a Miscellaneous bucket that starts with the claim that += is faster.

The manifest still says 3.0.0 but pins nox from 2024

The packaging metadata tells a more interesting story than the release history. The project is declared with Poetry under the name wtfpython at version 3.0.0, licensed WTFPL 2.0, with a single author. It requires Python 3.9 or newer. And it declares exactly one dependency, nox, pinned with a caret constraint to 2024.10.9, a version of nox published in late 2024. That single line is the clearest evidence of how the repository is actually maintained: the version field has not moved since 2019, while a dependency constraint has been refreshed four years later. It also tells you the shape of the project, since nox is a task automation tool for running test and lint sessions across interpreters, and this is a document with a verification harness rather than a package anyone installs. The build backend is poetry-core, and the readme declared to package is the README itself.

The Spanish translation is only reachable through a web archive

Seven translations are linked from the README and they are not maintained the same way. Three live in this repository under translations/, namely Russian and Persian, and they follow the master branch, so they are updated by the same commits as the English. Four live in separate repositories, covering Chinese, Vietnamese, Korean, and German, which means they are updated by whoever owns that fork. The fifth, Spanish, is different again: the link does not point to a repository at all, it points at an archived snapshot of one, hosted on a web archive. That is a specific and useful signal, because it means there is no live Spanish version to pull, only a frozen copy from 2022. New contributions go through an issue rather than a direct pull request, and the template asks for the expected time to finish in weeks and the date you intend to start, so the process is self-declared rather than gated.

Two interactive versions exist and neither is in the repository

Beyond the README, the project is available in two forms that live somewhere else entirely, and neither is in the git history. One is an interactive website, deployed on Vercel, where each example can be run in the browser. The other is an interactive notebook, the wtf.ipynb file from the irrelevant/ directory, published as a Google Colab notebook so it can be opened and executed without installing anything. That arrangement has a practical consequence for a reader deciding how to use this. The repository is the source of truth and the place to file issues, but the two things you would actually want day to day, a clickable playground and a runnable notebook, are hosted artefacts that can be replaced or taken down independently of the code. If you plan to teach from this, or to link to it, pin your own copy of the snippets rather than linking to the hosted site.

The slice assignment trick is the entry point most people miss

One example is worth singling out because it is the one that changes how you read the rest. The hidden treasures section opens with asking whether Python can make you fly, and the answer is a slice assignment that resizes a list, so you can insert and remove elements by assigning a slice of a list to a different sequence. It is the clearest demonstration of the idea the whole project is built on, which is that Python's mutating methods return None and therefore cannot be chained, so anything that looks like a fluent call on a list is really a language feature rather than a library. The section continues with goto implemented by raising an exception and catching it, brace indexing into a list and a string, a fluent alias for the string format method, the fact that the ellipsis object exists and can be assigned, an infinity built from a float literal, and name mangling of private attributes. Each entry is short enough to read in a minute and surprising enough to remember, which is the format the project is optimising for.

A single file at the root demonstrates a gotcha rather than shipping code

The repository layout contains one detail that tells you what kind of artefact this is. There is a Python file sitting at the top level named mixed_tabs_and_spaces.py, and it is not imported by anything. It is a demonstration, placed where someone cloning the repository will see it, of what happens when indentation mixes tabs and spaces. That is a small thing, but it is the clearest signal of intent in the file listing: this project is not built, it is demonstrated. There is no library to import, no module to depend on, and no API surface to keep stable. The cost of that choice is that you cannot version your dependency on it in any meaningful way, since there is nothing to pin. The benefit is that you can read the whole thing in an afternoon, copy a snippet into a scratch file, and find out what the interpreter actually does, which is the entire promise the project makes.

Editorial conclusion

WTF Python suits a Python developer who wants to understand why a piece of syntax behaves the way it does, and it is particularly good for the categories the author groups as slippery slopes, where a construct works until the moment it does not, and as hidden treasures, where the language quietly supports something you did not know existed. It does not suit you as a style guide, because the project never claims to be one and its own material is chosen for surprise rather than for what you should write, and it does not give you confidence that an example reflects a current interpreter, since the release that introduced the marked examples dates from 2019. Before quoting any of it in a codebase, run the snippet on the Python version you actually ship, and read the section name, which tells you whether the author is warning you or showing you a trick.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes