Tox is a neat tool for helping test Python projects. It automatically creates “virtual environments” that include the necessary dependencies, and can then run user-defined tools for testing. Multiple environments can be created in a declarative manner to test different combinations of Python versions + dependencies. Tox will also build packages in an isolated environment.

This has been an absolutely fantastic tool in its 15 years of existence. But since then, tooling in the Python ecosystem has moved on, and doing it the Tox way will probably slow you down.

You can get 90% of the value of Tox by wrapping Poetry or uv, and will end up with simpler, faster, and more flexible QA tooling. My preferred way to do that is to define tasks with Just, which enables something quite close to the npm run style development experience.

Cache-aware programming can make a huge performance difference, especially when writing code in C++ or Rust. Python is a much more high-level language, and doesn't give us that level of control over memory layout of our data structures. So does this mean that CPU caching effects aren't relevant in Python?

In this post, we'll conduct some basic experiments to answer this question, by accessing list element either in sequental order or in a random order.

Results indicate that randomized access is consistently slower in Python. Especially as soon as problem sizes outgrow the CPU cache sizes, random access is multiple times slower. Thus, some degree of cache-aware programming may be relevant in interpreted environments like CPython 3.12 as well.

While cleaning up some of my dotfiles, I found what may be the most cursed Python code I have ever written: raw syscalls that required parsing Linux header files.

When designing interfaces / APIs, it is easy to design the interface around the solution space. This makes such interfaces difficult to use, difficult to test, and difficult to maintain. Instead, our interfaces should allow users to easily express their intent.

Gcovr 4.2 is out, and provides a broad array of new features! With the ability to use config files, new output formats like JSON and SonarQube XML, and the ability to combine coverage data from multiple runs, this release should make it easier to create coverage report in more complex scenarios.

Gcovr is a command line tool that uses gcov to produce code coverage reports in various formats, such as text summaries, detailed HTML reports, and various machine-readable formats. It works with the GCC and Clang compilers.

You can pip install gcovr from PyPI, read the overview on GitHub, or read the full documentation.

After a lot of refactoring and cleanup, gcovr 4.0 is out!

This release represents four months of work. The focus was on internal changes, but there are lots of enhancements as well: better filters, improved Python 3 support, GCC 8 support, better encoding support via --source-encoding, parallel gcov invocations with -j, and HTML customizations with --html-title, --html-medium-threshold, and --html-high-threshold.

Gcovr is a command line tool that uses gcov to produce code coverage reports as text summaries, detailed HTML reports, or Cobertura-compatible XML. I works with the GCC and Clang compilers.

You can pip install gcovr from PyPI, read the overview on GitHub, or read the user guide.

I am excited to announce that gcovr 3.4 has been released!

This release represents over a year of accumulated bug fixes. Support for Windows and for Python 3 has been greatly improved. There are also a number of quality improvements behind the scenes.

Gcovr is a command line tool that uses gcov to produce code coverage reports as text summaries, detailed HTML reports, or Cobertura-compatible XML. I works with the GCC and Clang compilers.

You can pip install gcovr from PyPI, read the overview on GitHub, or read the user guide.

A few days ago, I was trying to split a data set into various files according to their type, but it was terribly slow. I saved an hour by taking a step back and thinking about my algorithms. Because algorithms matter. But not terribly much.

Using the recurrence relation $\binom n m = \binom {n - 1} {m - 1} + \binom {n - 1} m$, we develop a dynamic programming algorithm to calculate the binomial coefficient. I am aware that better algorithms exist.