fastprogress: nested progress bars and live training plots in Jupyter

What fastprogress solves, and for whom

A training loop has two loops inside it. The outer one counts epochs, the inner one counts batches. A single flat progress bar tells you nothing about which epoch is running or how far the current batch loop has gone. fastprogress addresses that by pairing a master_bar with one or more progress_bar objects that report to the parent.

The README describes the library as a fast and simple progress bar for Jupyter Notebook and console, and the package metadata in pyproject.toml calls it a nested progress with plotting options for fastai. The intended reader is someone writing a Python training or data-processing loop in a notebook, who wants a bar per loop level and a small chart of the loss curves rendered next to the bars.

The second thing it solves is the plot. Rather than opening a separate matplotlib figure that redraws on every epoch, master_bar exposes update_graph, which the README says creates the figure on its first use and then updates it in place. For a five-epoch run with two curves, that is the difference between watching a chart and re-running a cell.

The scope is deliberately narrow. There is no multiprocessing reporting, no structured logging, and no terminal dashboard. If your loop is a single flat iteration, a plain progress bar is enough and this library adds a dependency for nothing.

The master_bar and progress_bar mechanism

The API centres on two callables. master_bar takes an iterable and returns an object that is both iterable and a bar. progress_bar does the same for the inner loop, and accepts parent= to attach itself to a master. The README's first example assigns the master to a name with the walrus operator inside the for statement, which is the idiomatic form the library expects:

from fastprogress.fastprogress import *
from time import sleep

for i in (mb:=master_bar(range(10))):
    for j in mb.progress(range(100)):
        sleep(0.01)
        mb.child.comment = f'second bar stat'
    mb.main_bar.comment = f'first bar stat'
    mb.write(f'Finished loop {i}.')

Three attributes carry the state. mb.main_bar is the outer bar, mb.child is the inner one, and assigning to .comment on either replaces the text shown beside that bar. mb.write prints a line between the two bars, which is how you keep a running log of epoch results without breaking the bar layout.

The plotting side is a separate call, mb.update_graph. The README lists its arguments as graphs, a list of [x, y] pairs, plus x_bounds and y_bounds for the axis limits. It notes that supplying the bounds is preferable, because otherwise the box resizes as the loop progresses. Graph labels come from mb.names, which the README says should have as many elements as there are graphs.

One behaviour worth knowing before you rely on redirection: the README states that if a script using fastprogress is executed with output redirected to a file, only the results of the .write method appear in that file. Bar redraws are lost. That is a reasonable choice for a notebook-first library and a poor one if you were hoping the file would contain a transcript of progress.

Installing fastprogress and plotting a first loss curve

Installation is a single pip command, as the README states. The package metadata in pyproject.toml sets requires-python to >=3.10, so an older interpreter will refuse the install:

pip install fastprogress

After that, the import path used throughout the README is fastprogress.fastprogress. A minimal check is to import the two names and confirm they resolve, which is also the fastest way to rule out a stale environment:

from fastprogress.fastprogress import *

For a first real use, the README's third example is the one to copy. It defines a helper that computes axis bounds from the accumulated loss values and calls update_graph, then drives it from an emulated training loop. The helper takes epoch, epochs, the master bar and the two loss lists:

def plot_loss_update(epoch, epochs, mb, train_loss, valid_loss):
    x = range(1, epoch+1)
    y = np.concatenate((train_loss, valid_loss))
    graphs = [[x,train_loss], [x,valid_loss]]
    x_margin = 0.2
    y_margin = 0.05
    x_bounds = [1-x_margin, epochs+x_margin]
    y_bounds = [np.min(y)-y_margin, np.max(y)+y_margin]

    mb.update_graph(graphs, x_bounds, y_bounds)

Pass names=['cos', 'sin'] to master_bar if you want the curves labelled, as the README's second example does, since mb.names is tied to the graphs argument. In a notebook you should see the two bars stacked, with the chart appearing beside them on the first update and redrawing on each subsequent epoch. In a console run the README shows the same bars rendered as text, without the chart.

Where fastprogress is the wrong choice

The library is documented almost entirely by example. The README covers three usage patterns and stops. There is no reference for what happens when a loop raises an exception partway through, no statement about whether the bars are cleaned up, and no description of thread or process safety. If your training loop can fail and you need the progress state to reflect that, you are guessing.

The redirect behaviour is the sharpest limitation. Because only .write output reaches a redirected file, a job run under nohup or a scheduler will produce a log with your epoch summaries and nothing about intermediate progress. If you need per-batch records for later analysis, this library will not give them to you; you would write those lines yourself.

The plotting path also assumes a notebook or a console with a live display. update_graph is described in terms of creating and updating a figure, which has no meaning in a batch job with no display. The README does not document a headless mode or an option to disable plotting.

Finally, consider the dependency weight. pyproject.toml lists fastcore>=1.10.0 and python-fasthtml>=0.12.34 as required dependencies, not optional extras. Pulling in a web framework to draw a progress bar is a real cost if fastprogress is the only reason you are adding it, and it is the kind of thing worth checking against your existing environment before you commit.

One more caveat on the code you will find in the wild: the README imports with a wildcard from fastprogress.fastprogress. Naming the two functions explicitly avoids collisions with anything else in your namespace.

fastprogress against tqdm

tqdm is the obvious alternative and the comparison is instructive because the two differ in what they consider the main problem. tqdm's core is a wrapper around any iterable that renders a bar, with a large set of formatting and output options and adapters for pandas, command-line tools and log files. Nested bars exist there too, through the position argument, but you manage the positioning and the clearing yourself.

fastprogress inverts that. Nesting is the primary abstraction: master_bar owns the child, and the child reports through the parent rather than to the terminal. That is why mb.child.comment and mb.write exist as first-class calls instead of formatting options. The trade-off is that fastprogress gives you far less control over how the bar looks and where it goes, and it offers nothing comparable to tqdm's file and logging integrations.

The plotting is the other split. tqdm has no equivalent of update_graph; you would keep a separate matplotlib figure and redraw it yourself. If the loss curve beside the bars is what you actually want, fastprogress is doing work that tqdm leaves to you, at the cost of the extra dependencies and the notebook assumption. If you only need a bar in a script that writes to a log, tqdm is the smaller and more predictable choice.

Maintenance, release cadence and licence

The repository is not archived, and its last push was on 2026-09-04. Three releases appear in the record: 1.1.3 on 2025-12-29, 1.1.5 on 2026-02-13, and 1.1.6 on 2026-05-10. That is roughly a release every two to three months across that window, with commit activity continuing after the most recent tag.

The project is Apache-2.0, stated in pyproject.toml as license = {text = "Apache-2.0"} and present as a LICENSE file at the repository root. Apache-2.0 is permissive and includes an explicit patent grant, which matters more for a library that a company ships inside a product than for one used in a personal notebook. The usual obligation applies: retain the licence and notice files when you redistribute. Whether that obligation reaches your particular distribution model is a question for your own counsel, not for this article.

Upgrade cost is low on the evidence available. The public surface shown in the README is two constructors, a few attributes and one plotting method, and the version numbers moved through patch and minor increments. The one structural detail to watch is the Python floor: requires-python is >=3.10, so an environment pinned to 3.9 cannot take a current release. The package metadata also carries the classifier Development Status :: 4 - Beta, which is worth reading literally rather than as boilerplate.

There is no documented deprecation policy and no migration guide in the repository listing. If you pin fastprogress, pin it deliberately.

Editorial conclusion

fastprogress fits notebook or console training loops that need a parent bar, a child bar and a live loss plot in one object. It is the wrong tool for long-running services, for code that must log structured output, or for anyone who needs a documented API surface. Verify first that the master_bar and progress_bar names still resolve after installation, since the README imports them from fastprogress.fastprogress with a wildcard, and check the installed version against the 1.1.6 release on PyPI before you pin it.

Frequently asked questions

Official sources

1. AnswerDotAI/fastprogress on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases