Inconvenient behaviour in for loops

[oersted]

It is a common pattern in Python to wrap the iterator in a for loop with tqdm like so:

for _ in tqdm(iter):
    ...

This Rust version of tqdm advances the progress bar when calling .next(), which makes sense in principle.

However, say the iterator is trivially fast (like a Vec) and the slow computation is within the for loop, then the progress bar will tick from 0 to 1 almost immediately, and take a lot longer to go from 1 to 2 and so on. This causes the ETA to be vastly underestimated since it is artificially reduced by that first false iteration.

The original tqdm seems to somehow avoid this, it stays at zero until the first for loop has completed. Is there a clean way to address this flaw in such a common pattern?

[oersted]

This behaviour also means that it will be at 100% during the last iteration, which is rather confusing if the iterations are long.

[mrlazy1708]

Sorry for the late reply. I got you. You mean the following pattern

for _ in tqdm(0..) {
    thread::sleep(Duration::from_secs(10000))
}

will cause this confusing output (the same for 100%)

  1%|           | 1/100 [00:00<00:00, infit/s]

Yes I think it's clearer to give it the semantic "finished iteration" rather than "started". I need take time to consider if there's scenario where current implementation is semantically better. Thanks for your comments and I'll keep this in mind.

[mrlazy1708]

Should be fixed in 2f17dc3b33625c8d0ad7876145375b9a5d9f3523