ProgressBar2在PyCharm中无法正常工作

Question

因此，我正在尝试使用Python中的ProgressBar包。我目前正在将PyCharm 2020.1（社区版）与Python 3.8结合使用。暂时将进行一些计算，该过程中的所有内容都没有打印日志，我希望有一个进度条来跟踪此过程的状态，经过时间和ETA。为此，我决定搜索一个可以为我完成此任务的工具，并在PyPi上找到了实现所有这些的progressbar2软件包。现在，我有一个像这样的简单代码：

bar = ProgressBar(start=0, maxval=len(data))
i = 0
for d in data[:]:
    # Some computation
    i += 1
    bar.update(i)
bar.finish()

重要的是，我试图调用三个函数，它们显示相似的进度条，但值略有不同。尽管如此，以下是我得到的结果：

[READER] Downloading 506 tickers
100% (506 of 506) |######################| Elapsed Time: 0:00:04 Time:  0:00:04
N/A% (0 of 503) |                        | Elapsed Time: 0:00:00 ETA:  --:--:--[READER] Dumping 503 tickers to CSV
100% (503 of 503) |######################| Elapsed Time: 0:00:03 Time:  0:00:03
N/A% (0 of 503) |                        | Elapsed Time: 0:00:00 ETA:  --:--:--[READER] Compiling 503 tickers
100% (503 of 503) |######################| Elapsed Time: 0:00:06 Time:  0:00:06

如您所见，我得到的是下一个进度条的内联表示，而不是只获取完成的条并在下一个开始之前打印所需的字符串。不知道它是否打算那样工作，或者是我做错了什么，还是PyCharm控制台本身存在兼容性问题。

感谢您的任何建议...

更新：有时它可以按预期工作，而无需更改它们之间的任何代码或处理。如下所示：

[READER] Downloading 506 tickers
100% (506 of 506) |######################| Elapsed Time: 0:00:02 Time:  0:00:02
[READER] Dumping 502 tickers to CSV
100% (502 of 502) |######################| Elapsed Time: 0:00:01 Time:  0:00:01
[READER] Compiling 502 tickers
100% (502 of 502) |######################| Elapsed Time: 0:00:03 Time:  0:00:03

Answer 1

说明

progressbar模块具有a known issue with PyCharm。问题在于stderr和stdout之间的时序似乎是完全随机的，从而导致交错结果。 It has since been mitigated enough to not be an issue for most people using the progressbar module, but it's possible that it's still present。由于progressbar将写入ProgressBar(start=0, maxval=len(data))，而您的stderr函数将写入print，因此看来这可能是问题所在。

解决方案

如果我们假设是问题所在，stdout。例如，将两者都写入you can use a single output stream instead：

stdout

但是，如果您坚持要同时使用，

import sys

# Write ProgressBar to stdout
bar = ProgressBar(start=0, maxval=len(data), fd=sys.stdout)

i = 0
for d in data[:]:
    # Some computation
    i += 1
    bar.update(i)
bar.finish()

。因此，就您而言，类似：

it's been recommended to wait ~200 milliseconds for the next output or it may break