Progress bar with multiple backends
This article introduces a simple manner about integrating different
Progress Bar
backends in Python.
Introduction
Progress Bar: A progress bar is a graphical control element used to visualize the progression of an extended computer operation, such as a download, file transfer, or installation. Sometimes, the graphic is accompanied by a textual representation of the progress in a percent format. The concept can also be regarded to include “playback bars” in media players that keep track of the current location in the duration of a media file.1
In recent decades, the progress bar may not have changed much in
form, but it has derived many more profound connotations such as
progress bar user experience
and
progress bar design philosophy
. But, the latter two are not
our concern in this article. Here we only talk about how to integrate
multiple backends in Python.
(From ChatGPT ) There are many continuously updated light progress bar tools or big libraries that contains progress bar widgets in Python, such as :
- tqdm:
tqdm
means “progress” in Arabic (taqadum, تقدّم) and is an abbreviation for “I love you so much” in Spanish (te quiero demasiado). 2 - progressbar2: The progressbar is based on the old Python progressbar package that was published on the now defunct Google Code.3
- alive-progres:
Introducing the newest concept in progress bars for Python!
alive-progress
is in a class of its own, with an array of cool features that set it apart. 4 - yaspin:
Yaspin
provides a full-featured terminal spinner to show the progress during long-hanging operations.5 - rich: Rich is a Python library for writing rich text (with color and style) to the terminal, and for displaying advanced content such as tables, markdown, and syntax highlighted code.6
- tf.keras.utils.ProgBar: Displays a progress bar.7
Why we need progress bar
in Python?
Generally and natively, to monitor the status of a computer or a program, we may print out some information at some nodes when running. But when it comes to a big project or program, a huge of data will be printed out at last in a run, which may exceed the text limitation of the terminal window. And as a consequence, our print-out information will lose its meaning since it cannot be checked totally.
For example, a deep learning training program based on TensorFlow/Keras may require millions of loops (steps). Although we print out loop indices and other information per 100 or 1000 steps, we still will encounter thousands of print-out entries on the terminal, which is no doubt a disaster since we cannot check all of them by poor-functional terminal windows. Seriously, if the terminal is flooded with information, then the content in the terminal will lose its meaning.
A common method to deal with the above problem is to divide
monitoring behavior into logging
and
progress bar
, where logging
records our
concerned information to the terminal window and files, and
progress bar
shows progress information on the terminal
window or in other forms. The advantage of logging
is it
will record anything we want toward files even though the data exceeds
the text limitation of the terminal window. We can still print out
information on the terminal window but we no longer rely on it to check
all the information but only consider it as a monitoring method. But
logging
is not the main idea of this article and it will be
talked about in later articles. Here we only talk about
progress bar
.
Methods and Results
Here we post 2 methods that integrate alive-progres and tf.keras.utils.ProgBar. The principle is the same if merge into other backends.
Patch a function with bar
Consider a function with bar
argument as:
1 | def test_func(bar:Callable=None): |
If we want this function to show progress bar when its called procedure, we cam make a decorator function as:
1 | import logging |
Then the usage is as:
1 |
|
The testing result is shown as the following:

Support contextual syntax
Consider a usage with bar()
as:
1 | for _ in range(1000): |
If we want to use bar()
with a context manager, we can
define a customize class as:
1 | import functools |
Then the usage and testing are as:
1 | with CustomBar(20,'TestBar',backend='keras') as bar: |
The testing result is shown as the following:

If one get used to functional form, a modified way can be:
1 | def my_bar(total:int,title:str='UnknownBar',backend:Literal['keras','alive_progress']='alive_progress',**kwargs): |
Then the usage and testing are as:
1 | with my_bar(20,'TestBar',backend='keras') as bar: |
The testing result is shown as the following:

Analysis and Conclusion
In this article, we post 2 simple methods to make a customized
progress bar
with integrated alive-progres and
tf.keras.utils.ProgBar
as backends.
- The first method can be used to patch a existent function who has a
bar
argument. To realize the patching,inspect
andParameter
are used. - The second method can be used when one want a context manager to
manage
progress bar
behavior. To realize the context manager,__enter__
and__exit__
should be override.
It is not difficult to find that if we want to integrate other backends, the basic pattern is the same. It is nothing else but:
- Know the original (native) usage of the backend that will be
integrated.
- Supported usage.
- Is
with
supported? - If
add()
function need arguments? - …
- Use the knowledge of python development to embed the backend, according the specific backend.
The main problem is, if 2 backends has different usages, like alive-progres and
tf.keras.utils.ProgBar,
where the former only support with
and the later only
support non-with
, we need to write many extra codes to
combine them together with harmony. Therefore, this is the cost of
integration.
The more integrated, the less commonality. The more
if-else
, the more complexity. In the exemplification of
this article, we have increased the commonality and reduced the
complexity (only the necessary if-else
is retained) as much
as possible.
(2023, April 30). Progress bar - Wikipedia. En. https://en.wikipedia.org/wiki/Progress_bar ↩︎
(2023, April 30). tqdm documentation. Tqdm. https://tqdm.github.io/ ↩︎
(2023, April 30). Welcome to Progress Bar’s documentation! — Progress Bar 4.3b.0 documentation. Progressbar-2. https://progressbar-2.readthedocs.io/en/latest/index.html# ↩︎
(2023, April 30). rsalmei/alive-progress: A new kind of Progress Bar, with real-time throughput, ETA, and very cool animations!. Github. https://github.com/rsalmei/alive-progress ↩︎
(2023, April 30). pavdmyt/yaspin. Github. https://github.com/pavdmyt/yaspin ↩︎
(2023, April 30). Introduction — Rich 13.3.5 documentation. Rich. https://rich.readthedocs.io/en/latest/introduction.html ↩︎
(2023, April 30). tf.keras.utils.Progbar | TensorFlow v2.12.0. Tensorflow. https://www.tensorflow.org/api_docs/python/tf/keras/utils/Progbar ↩︎