This is nice if you have non-homogeneous tasks that need updating as different parts of the code are reached; for showing a progress bar when performing work on an iterable, tqdm seems simpler as it’s just one function call wrapping the iterable : https://pypi.org/project/tqdm/
Tqdm also has a “manual update” mode as a context manager, which looks comparable to lowbar.
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.
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.
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.
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
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.
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.
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)
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
Tqdm also has a “manual update” mode as a context manager, which looks comparable to lowbar.