Allow hiding progressbar until some time interval has elapsed.

[anntzer]

This avoids printing the progressbar for very short loops, i.e. the feature requested in #704. I am not particularly wedded to the kwarg name, alternatives are welcome.

[codecov-io]

Codecov Report

Merging #836 (90cb341) into devel (d710226) will decrease coverage by 0.05%.
The diff coverage is 83.33%.

@@            Coverage Diff             @@
##            devel     #836      +/-   ##
==========================================
- Coverage   84.81%   84.75%   -0.06%     
==========================================
  Files          24       24              
  Lines        1613     1620       +7     
  Branches      265      267       +2     
==========================================
+ Hits         1368     1373       +5     
- Misses        208      209       +1     
- Partials       37       38       +1     

[anntzer]

Kindly bumping, thanks!

[casperdcl]

Nice but maybe use an existing kwarg?

[casperdcl]

@anntzer how about using disable=<float> instead?

We could do:

if disable and disable not in (True, 1):
    disable = False
    waituntil = disable

This would be backward-compatible without adding yet another kwarg (similar to unit_scale):

tqdm/tqdm/std.py

Line 380 in 80be780

if unit_scale and unit_scale not in (True, 1):

[anntzer]

It's not clear to me these can be combined -- what if I want to use waituntil=1 for example?

[casperdcl]

Yes as with unit_scale it would be treated the same as True. You'd need 0.99 or 1.01 etc if you really wanted approx 1 second

[anntzer]

But then I fail to see why you want to combine these into a single kwarg (I'm all for not adding more kwargs than necessary, but not at the cost of combining unrelated stuff)... disable and waituntil have completely different semantics, and the combination you propose just looks... confusing?
Another way to look at it is, what docstring do you propose?

disable : bool or float, optional

If True, the entire progressbar wrapper is disabled.
If None (the default), the progressbar wrapper is disabled on non-TTY.
If a float value other than 1, the progressbar is not displayed until disable seconds have elapsed

?

[casperdcl]

Something like:

    disable  : bool or float, optional
        [default: False].
        If True or 1, disable the entire progressbar wrapper.
        If None, disabled on non-TTY.
        If any other numeric value, wait until the specified number
        of seconds have elapsed.

[anntzer]

Let me rephrase my query, then: Are willing to merge (or at least review) a PR which introduces the feature under the disable kwarg? If so, then I am willing to ignore my opinion that folding the feature into disable is a mistake.

[casperdcl]

I think we're willing to merge this feature, and there are 2 ways to expose it to an end user (new kwarg or augment existing kwarg). Both are easy to implement, but I don't know what users will find best. More opinions from other people would help.

advantages:

• new kwarg
  • no risk of breaking backward compatibility
  • supports exactly 1 second
• augment disable
  • no additional kwarg clutter
  • no need to decide on new kwarg name
  • consistency: same implementation approach as unit_scale

[anntzer]

OK, I'll let you figure this out then :) (I have already given my arguments above, and don't have much to add.)

[graue70]

I'm definitely pro new kwarg. The alternative is WAY confusing. It would make it basically impossible to find the feature at all. If one does, one can use any amount of seconds except 1? Really?

Using unit_scale for two things is less bad because nobody wants an actual unit_scale of 1.

[Witiko]

@casperdcl I agree with @graue70 and @anntzer. Folding waituntil into disable seems hostile to the user w.r.t. discoverability and the unintuitive casting of 1.0 to a boolean. As for an alternative name, how about delay?

[casperdcl]

fixes #1069
fixes #704