Python output in IntelliJ IDEA is out of order-CodePudding

I have a very simple Python program.

def square(a):
    for i in a:
        yield i*i

def main():
    a = [1, 2, 3]
    b = square(a)
    print(b)
    print(next(b))
    print(next(b))
    print(next(b))
    print(next(b))


if __name__ == "__main__":
    main()

When I run it from the command line, I got the following result, which is what I was expecting.

c:\test1>python main.py
<generator object square at 0x000002982E07A4A0>
1
4
9
Traceback (most recent call last):
  File "main.py", line 16, in <module>
    main()
  File "main.py", line 12, in main
    print(next(b))
StopIteration

c:\test1>

I run it many times and the result is always the same. However, when I use IntelliJ IDEA with Python plugin to run the same program, I got this:

C:\Python\python.exe c:/test1/main.py
Traceback (most recent call last):
  File "c:/my_projects/python1/main.py", line 16, in <module>
    main()
  File "c:/my_projects/python1/main.py", line 12, in main
    print(next(b))
StopIteration
<generator object square at 0x000001799923C580>
1
4
9

Process finished with exit code 1

Or this:

C:\Python\python.exe c:/test1/main.py
<generator object square at 0x00000230F551C580>
1
4
9
Traceback (most recent call last):
  File "c:/my_projects/python1/main.py", line 16, in <module>
    main()
  File "c:/my_projects/python1/main.py", line 12, in main
    print(next(b))
StopIteration

Process finished with exit code 1

Why does this happen? How to get a stable result in IntelliJ IDEA?

CodePudding user response：

The Kemp's explanation is correct.

There is a corresponding ticket in PyCharm issue tracker https://youtrack.jetbrains.com/issue/PY-37396

As a possible workaround, you can enable Emulate terminal in output console option for your run configuration (Run | Edit Configurations...).

CodePudding user response：

The issue here is that the print output goes to stdout while the exception message goes to stderr. In your terminal they get output as-is, but the IDE is likely doing some buffering on stdout for efficiency reasons. The same buffer won't apply to stderr because it needs to make sure that output gets on the screen asap and without risking the buffer being prematurely cleared out. This means that sometimes (quite often in my experience) exception messages like yours will appear before normal output that you'd expect to already have been shown.