Lowbar – The simplest no-nonsense loading bar for Python(github.com)
github.com
Lowbar – The simplest no-nonsense loading bar for Python
https://github.com/AnnikaV9/lowbar
35 comments
tqdm also supports Jupyter Notebooks, which is really nice.
And it has no dependencies
Thanks for the feedback! I was going for something different from already available loading bars, giving users maximum control while keeping the code base small.
im getting into python this week after lots of years of doing other stuff and i appriciated how little code there was and how it was simple enough to get my head around quickly. thanks for sharing stranger.
This started as a quick little experiment with sys.stdout, but turned into something somewhat useful!
tqdm (Arabic word taqaddum — "progress") reminds Z'Ha'Dum from Babylon 5 https://youtu.be/jdoZvo8j6tc
One way in which it is not simple is that you can't set what the "max" of the bar is and have it auto-calculate the percentage. Like, if I have 7 tasks to accomplish, I have to manually keep track of the percentage to increase it by, and since 7 doesn't increase cleanly, I probably have to custom-code the final update to 100 manually, or it'll be just under or over, depending on how I round. Or maybe I have a variable number of tasks, and instead of increasing by a constant, I have to have separate variables for calculating the amount to increase by.
I know every feature added to something simple adds unforeseen levels of complexity, but this choice doesn't eliminate complexity, it just moves the complexity to calling code, and for nearly every use case.
I know every feature added to something simple adds unforeseen levels of complexity, but this choice doesn't eliminate complexity, it just moves the complexity to calling code, and for nearly every use case.
> since 7 doesn't increase cleanly, I probably have to custom-code the final update to 100 manually,
What do you mean with "not cleanly"?
bar.update_smooth(i * 100 / 7)
Once i is 7, this will be equal to 100. No matter your rounding mode. You don't need a CS degree for that formula.
What do you mean with "not cleanly"?
bar.update_smooth(i * 100 / 7)
Once i is 7, this will be equal to 100. No matter your rounding mode. You don't need a CS degree for that formula.
Percentage calculations require multiplying or dividing by 100 in the right places, complicating both the progress bar itself and client code.
In typical usage it would be more elegant and more general to have a fraction, x things done out of a total of y, with both x and y updateable.
For example, recursively enumerating the contents a file system interleaves increasing y (when subfolders are visited and unprocessed files and unvisited subfolders are found) with increasing x (when files and folders are processed/visited). At the end x catches up with y.
Lowbar could be easily adapted to a percentage-free style without backwards incompatibilities: the constructor could have a parameter, range with default 100, and new methods update_range() and update_range_smooth() could update y similarly to how update() and update_smooth() update x.
For example, recursively enumerating the contents a file system interleaves increasing y (when subfolders are visited and unprocessed files and unvisited subfolders are found) with increasing x (when files and folders are processed/visited). At the end x catches up with y.
Lowbar could be easily adapted to a percentage-free style without backwards incompatibilities: the constructor could have a parameter, range with default 100, and new methods update_range() and update_range_smooth() could update y similarly to how update() and update_smooth() update x.
The simplicity of this project isn't really in the usage, but the code base. I guess my main goal was to make a bar that was different from already available loading bars, and give as much control to the user as possible, while keeping the amount of code minimal. Thanks for the feedback though :D
Yes, it's up to you to determine the progression of the program. You can keep track in fractions of 1 with casts and a bit of math.
Perhaps you can use a prediction library such as Prophet (by Facebook) to predict the ETA.
[deleted]
I love it that such trivially simple piece of code can gain attention of HN at some moment, with reasonable critique in comments.
yes! i did not expect it to get this much attention, since i thought no-one would find it useful due to easier to use bars like tqdm ;-;
Very low bar, even pip is using the rich terminal library now (that's how you get all the RGB animations).
Might be adding color support in the future :P
I think there's an issue somewhere. I was getting "AttributeError: module 'lowbar' has no attribute 'lowbar'. Did you mean: 'LowBar'?" until I changed "LowBar" to "lowbar" in lowbar.py using the example code.
Looks great though!
Looks great though!
this issue has been fixed! thanks for the feedback :D
Great job! Really cool solution here. I agree with the other comment that tqdm is simpler for iterables. Maybe see if you can abstract some of your logic to provide a wrapper function like tqdm does.
Thanks for the feedback! I was aiming for something different from other loading bars, even if it's a niche use case
I love this. One tiny thought - perhaps use a conditional when setting the string percentage/completion value to prepend a 0 of it's < 10?
like: completion_string: str = '0' + str(self.completion) if self.completion < 10 else str(self.completion)
basically it would keep your bar from shifting when percentage goes from single digit to double digit.
like: completion_string: str = '0' + str(self.completion) if self.completion < 10 else str(self.completion)
basically it would keep your bar from shifting when percentage goes from single digit to double digit.
This is a pretty good idea, thank you! I will implement this, but instead of a zero ill use a whitespace
You may want to use Format specifiers or fstrings (>py36) for a „more pythonic“ code.
Also why do you annotate every variable, even if the type can be deduced automatically? That’s going to be a real PITA if you want to refactor the code e.g to support floats instead of ints any time in the future (in this case it’s probably just a hypothetical problem)
Also why do you annotate every variable, even if the type can be deduced automatically? That’s going to be a real PITA if you want to refactor the code e.g to support floats instead of ints any time in the future (in this case it’s probably just a hypothetical problem)
its mostly for myself, i prefer to annotate variables so i can quickly know what type they should be when writing code (especially for bigger projects). I guess since lowbar is small, its pretty pointless, but its just a habit thats been stuck
The big question is does it work with Pycharm?
Why is that a big question?
Tqdm also has a “manual update” mode as a context manager, which looks comparable to lowbar.