Thanks for sharing this feedback - let me see if I can help out a bit.
I’m not sure what version of the book you might be reading (some early versions didn’t mention a companion Docker image), but the easiest way to try out the tools is to use the book’s companion Docker image:
docker run --pull=always --interactive --tty --rm ghcr.io/davidmuller/intuitive-python-book/intuitive-python-book:latest /bin/bash
After executing step 2, you’ll be logged into the Docker container as a user named
monty in a directory with all the book’s source code. Use this space as a sandbox to run all the code examples as you read the book.
As you read through the book, you’ll see examples for how to invoke
flake8 appear in the text. For example,
flake8 variable_does_not_exist.py is one such invocation described in the section titled
Detecting Undefined Variables.
Similarly, in the section titled
Finding Unsupported Arguments, the text describes invoking
Both of these examples demonstrate how to invoke
mypy against a single file. These examples should run successfully if you are inside of the companion Docker image (which includes all the book’s source code examples).
If you’re curious to learn more about invoking
mypy, I recommend their help commands (
mypy --help) and their online documentation (flake8, mypy).
As you point out, however, the book does not have a concrete example for how to invoke
black. Just like
mypy, one way to invoke
black is against a single file.
For example, you can run
black --diff gil_example.py inside the Docker image to see some changes
black would make to
gil_example.py. If you remove the
--diff and just run
black will write out the changes you previewed in the first command to disk.
If you’re curious to learn more about
black, I recommend its help command (
black --help) and its online documentation.
what a build system is and how to set it up?
You’re right, build systems are not covered explicitly in the book. You can think of a build system as a server that automatically runs tests and other validations every time you change the source code in a project.
If you’re familiar with GitHub, you may have seen an example build system already. GitHub includes a product called GitHub Actions, which is a build system for developers who store their source code on GitHub. Those developers are able to run tests and other programs anytime they change their code on GitHub. These builds help developers catch bugs and other problems early—before, for example, they actually formally release their code for others to use.
(For a concrete example of a build system, you can visit the GitHub repository that stores the code that implements the Python language itself. Every time the developers of the Python language change the code that powers the language, a suite of builds + tests + validations are run. You can view the output of those Python language builds here.)
Running Example Commands for a Build System
mypy are three tools that the book recommends running any time you change your Python source code. You can use a build system / server to run these tools for you, but you can also run them manually:
# navigate to your project code
$ cd /example/path/to/your/project/code
# make sure all the files in your project are black compliant (the . is important)
$ black --check --diff .
# run flake8 against all files in your project (the . is important)
$ flake8 .
# run mypy against all the files in your project (the . is important)
# (--pretty makes the results a little easier to read)
$ mypy --pretty .
Thanks for checking out the book. I hope some of the discussion here adds additional context for the book.