wanna be even fancier here?
ATM if progress message would be reported before actual computation is done, it would report 0sec left while it still need to do the last computation... and that 0s can be arbitrarily long depending on that last computation duration.  So ideally here (or may be in eta_string) -- should be 1 more argument which would tell either this reporting is done before or after computation,  and then instead of a "progress" ProgressBar should be initiated with total number of iterations to be done, and current iteration given to __call__.  Then if "after" -- nothing to adjust here.  if 'before', then ... ok -- probably in ProgressBar then only -- compute progress with accounting for "-1".     That would also avoid duplication of computing progress ratio "manually" for every call to ProgressBar... just an idea ;)