Merge to progressbar2

[KOLANICH]

• I have marked all applicable categories:
  • new feature request
• I have visited the [source website], and in particular
  read the [known issues]
• I have searched through the [issue tracker] for duplicates

progressbar2 has a concept of widgets. It allows library user to set up what is to be shown.

I guess it may make sense to merge the 2 projects.

@wolph

[casperdcl]

Are there any features in progressbar2 that are not supported by tqdm? We use bar_format instead of widgets

[KOLANICH]

We use bar_format instead of widgets

Widgets are objects, bar_format is a string. This means that it is cleaner to implement extendability and lazy evaluation for widgets (just iterate over widgets calling their methods) than for bar_format (either rewrite everything into widgets, then create code parsing bar_format generating widgets, or doing everything in a dirty way as it is done currently).

Are there any features in progressbar2 that are not supported by tqdm?

Custom variables + extendability, I guess. Also there are some features as spinners (but IMHO progressbars should be used as much as possible because they are more informative).

[wolph]

Disclaimer 1: I'm the author of Progressbar 2
Disclaimer 2: Progressbar 2 is a fork of progressbar that was written by Nilton Volpato. Since that project was abandoned for many years I decided to fork and improve it.
Disclaimer 3: Progressbar 2 is designed to be a drop-in replacement for Progressbar and tries really hard to maintain backwards compatibility so all of the old/existing code keeps on working.

As for features that tqdm does not support... I know at least one pretty big feature that makes progressbar2 fairly unique and is a huge maintenance hog. The support for output redirection and plain ansi rewrites in most shells/environments. This means that you can still use normal print and logging statements while using the progressbar. And this even works in environments such as PyCharm, Jupyter, Windows consoles, etc.

For example:

import time
import progressbar

for i in progressbar.progressbar(range(3), redirect_stdout=True):
    print('Processing %d' % i)
    time.sleep(0.1)

This results in:

Processing 0
Processing 1
Processing 2
100% (3 of 3) |#########| Elapsed Time: 0:00:00 Time:  0:00:00

Whereas tqdm results in:

  0%|                               | 0/3 [00:00<?, ?it/s]Processing 0
 33%|███████▋               | 1/3 [00:00<00:00,  9.59it/s]Processing 1
 67%|███████████████▎       | 2/3 [00:00<00:00,  9.67it/s]Processing 2
100%|███████████████████████| 3/3 [00:00<00:00,  9.63it/s]

I'm aware of the redirecting of writes that optionally supported, but that's not integrated in such a way that it would work with logging for example.

While I personally wouldn't be against merging the repositories, I don't think it's going to happen any time soon because the APIs between the two is very different and it would be hard to write a compatibility layer that translates one into the other.

[casperdcl]

@wolph yes we use tqdm.write() instead of print() - well done for putting in the effort to try to support it automatically; but surely people who already mess with sys.stdout/err will then be affected?

@KOLANICH

• do you mean "add tqdm=self to format_dict" as a feature request?
• for spinners, you could do something like ascii=" " + "-\|/" * (total // 4), bar_format="{l_bar}{bar:1}{r_bar}" but I agree it's easily improvable.

[KOLANICH]

These all are just workarounds.

[wolph]

@wolph yes we use tqdm.write() instead of print() - well done for putting in the effort to try to support it automatically; but surely people who already mess with sys.stdout/err will then be affected?

There are a few exceedingly rare cases where can be problematic but in most cases it works transparently without causing issues. As I said, it's definitely a maintenance hog to keep it working like that :P

I should note that I never would have started this project if tqdm would have been available at that time. Having two well maintained projets that effectively do the same is simply a waste of resources. As is the case with many of the projects I maintain. Eric Raymond said it well: "Every good work of software starts by scratching a developer's personal itch."

[casperdcl]

@wolph hah yes I started with tqdm back when I found about 10 equally-used python progress bar packages all of which I was unhappy with. It's not so bad to have alternatives which solve almost the same problem - there could be things which are much easier to support in one, and ideas can come from more places. Monopoly is a crime :)

[wolph]

That's very true :)
For what it's worth the tqdm source looks quite nice and the project is very well documented as well. You definitely did a good job!

As for the rewrite thing, I noticed another difference while looking through the source. progressbar2 works by solely rewriting the current line with \r. I notice that tqdm uses the "move" commands to move up/down (which is effectivly the only way to support a multi-line bar). The downside of that approach is that it works in a limited amount of environments. The PyCharm editor and Jupyter console both have problems parsing those commands.

I am working on an optional multi-bar approach which does use the move commands to function, but those will have the same downsides that they only function in a limited amount of shells.

[casperdcl]

yes that's why we have tqdm.notebook and in theory other submodules for other frontends... Your projects are also clean which makes sense given that you wrote a book - was it in the humble bundle packt python thing a few months ago? :D

I think the documentation is probably the main reason why tqdm became so popular.

[wolph]

Yes I've noticed that. Those submodules are a really nice touch to make it work in more environments :)

As for the book, it very well might have been. I honestly don't keep track too much when it's on sale. I'm working on an updated version which hopefully addresses all of the issues the previous book had so if you have any suggestions please let me know :)

[IlyaOrson]

For what it's worth, for some use cases one relevant difference might be the license.