Spyder: The external system terminal close after running script if the Python console exits due to an exception

[jnsebgosselin]

Issue Report Checklist

• [x] Searched the issues page for similar reports
• [ ] Read the relevant sections of the Spyder Troubleshooting Guide and followed its advice
• [x] Reproduced the issue after updating with conda update spyder (or pip, if not using Anaconda)
• [x] Could not reproduce inside jupyter qtconsole (if console-related)
• [x] Tried basic troubleshooting (if a bug/error)
  
  
  
  • [x] Restarted Spyder
  
  
  • [x] Reset preferences with spyder --reset
  
  
  • [x] Reinstalled the latest version of Anaconda
  
  
  • [x] Tried the other applicable steps from the Troubleshooting Guide
  
  
• [x] Completed the Problem Description, Steps to Reproduce and Version sections below

Problem Description

Especially when testing code involving PyQt or PySide, I often like to execute my code using an external system terminal on Windows with the option Interact with the Python console after execution checked.

However, very often when an exception is raised during execution, the Python console and the external system terminal both close, so that it is impossible to see the traceback of the error.

Below is a minimal working example I've put together that allow to reproduce this behavior on my system:

import sys
from PyQt5.QtWidgets import QPushButton, QWidget, QApplication, QGridLayout


class SomeClass(QWidget):
    def __init__(self):
        super().__init__()
        layout = QGridLayout(self)
        btn_crash = QPushButton('Crash')
        btn_crash.clicked.connect(self.crash)
        btn_crash2 = QPushButton('Crash2')
        btn_crash2.clicked.connect(self.crash2)
        btn_close = QPushButton('Close')
        btn_close.clicked.connect(self.close)
        layout.addWidget(btn_crash)
        layout.addWidget(btn_crash2)
        layout.addWidget(btn_close)

    def show(self):
        super().show()

    def crash(self):
        raise ValueError

    def crash2(self):
        return self.crash2()


if __name__ == '__main__':
    app = QApplication(sys.argv)
    window = SomeClass()
    window.show()
    sys.exit(app.exec_())

What steps reproduce the problem?

1. Run the script in an external system terminal in Spyder with the option Interact with the Python console after execution
2. Click on Close button
3. Run the script again
4. Click on Crash or Crash2 button

What is the expected output? What do you see instead?

When clicking on the Close button, the Python console and the terminal do not close and it is indeed possible to interact with the Python console after execution. When either the Crash or Crash2 button is clicked, the Python console and the external system terminal both close, so that it is impossible to see the traceback of the error.

What I have done to go around this behavior on my system is to change the way the external system terminal is started in Windows from (see here) :

cmd = 'start cmd.exe /c "cd %s && ' % wdir + ' '.join(p_args) + '"'

to (see https://stackoverflow.com/a/46882828/4481445) :

cmd = 'start cmd.exe /K "cd %s && ' % wdir + ' '.join(p_args) + '"' + ' ^&^& exit'

This prevents the external system terminal from closing when the Python console exit with an error code other than 0. If there is no error though, then the terminal is closed automatically like before.

Versions

• Spyder version: Spyder 4.0.0.dev0
• Python version: Python 3.7.1 64-bit
• Qt version: Qt 5.9.6
• PyQt version: PyQt5 5.9.2
• Operating System name/version: Windows 10

[goanpeca]

@jnsebgosselin I guess this is also happening for 3.x?

[jnsebgosselin]

@jnsebgosselin I guess this is also happening for 3.x?

Yes, It should do the same thing in 3.x. However, I do not consider the current behavior to be a bug per se, though I think that implementing the change I'm proposing, either as the default or as an additional option, would be a great Ux-usability improvement.

[goanpeca]

I think this could go then on the 3.x series @ccordoba12 ?

Yes, It should do the same thing in 3.x. However, I do not consider the current behavior to be a bug per se, though I think that implementing the change I'm proposing, either as the default

I would prefer default, I do not see how useful is the current behavior, nor providing an option for that (also it makes it easier to bubble up the change to master :-p)

But I would like to hear opinions :-) @spyder-ide/core-developers

[CAM-Gerlach]

I agree, @goanpeca ; I don't see how immediately closing the terminal window if an error occurs (thus hiding the error, and possibly even that an error occurred at all) would ever be what a user would want or expect. In the worst case, they can spend a second closing it themselves, which is nothing compared to the cost of the alternative in the most likely case.

[goanpeca]

@jnsebgosselin could you work on a fix aimed at the 3.x branch? No configuration needed :-)

[jnsebgosselin]

Cool, I'll prepare a PR then.