Prevent vscode from exiting the Python interpreter a script completes

[brettcannon]

Discussed in microsoft/vscode-python#16082

^{Originally posted by larsoner April 29, 2021}
The way I have used Python for years (through Spyder, directly from a bash terminal, etc.) is to execute a script in interactive mode such that once it's done, you can interact with it, e.g.:

python -i script.py

VSCode's debugger does not give a way to get this behavior currently. And it seems like I am not the only one looking for it:

• https://stackoverflow.com/questions/56568304/how-to-run-my-python-module-in-visual-studio-code-in-interactive-mode
• https://stackoverflow.com/questions/54609806/how-to-prevent-vscode-from-exiting-python-environment-after-running-code
• https://www.reddit.com/r/vscode/comments/8uv8xc/how_to_keep_python_running_after_script_execution/
• Python Debugger - using python in interactive mode via PYTHONINSPECT vscode-python#5497

One workaround is to put a breakpoint at the end of your file, but this requires extra work.

Another workaround is to add "env": {"PYTHONINSPECT": "true"}, to the launch configuration with integratedTerminal, but this doesn't work properly as any input is captured and newlines aren't treated properly while printing, which makes it pretty unusable.

I could see at least two potential solutions (the first would be better I think):

1. Make it so that in PYTHONINSPECT mode, the terminal could be interacted with properly, possibly by adding a new inspectOnExit or something that ran in -i / PYTHONINSPECT mode and returned proper input/output when the script completes. Based on Python Debugger - using python in interactive mode via PYTHONINSPECT vscode-python#5497 it sounds like this is a no-go, though.
2. Add a stopOnExit debug option to mirror stopOnEntry in the debugger. This way at least variables could be inspected using the vscode debugger.

[brettcannon]

Thanks for the feature request! We are going to give the community 60 days from when this issue was created to provide 5 👍 upvotes on the opening comment to gauge general interest in this idea. If there's enough upvotes then we will consider this feature request in our future planning. If there's unfortunately not enough upvotes then we will close this issue.

[happyTonakai]

Is there any updates?

[brettcannon]

Thank you to everyone who upvoted this issue! Since the community showed interest in this feature request we will leave this issue open as something to consider implementing at some point in the future.

We do encourage people to continue 👍 the first/opening comment as it helps us prioritize our work based on what the community seems to want the most.

[EdjeElectronics]

One year later - I would love to see this implemented! Staying in an interactive Python shell after running a script (like IDLE does) is extremely useful for helping to debug a program or learn a new library.

[James-E-A]

:^)

... # script body # ...

if __name__ == '__main__':
    ... # main() # ...

    # Workaround for https://github.com/microsoft/vscode-python-debugger/issues/524
    import os
    if __debug__ and os.environ.get('TERM_PROGRAM') == 'vscode':
        breakpoint()
        pass  # Workaround for https://github.com/python/cpython/issues/111744
#EOF

https://docs.python.org/3.7/library/functions.html#breakpoint

[eleanorjboyd]

What are people's thoughts on how this would be set up? Would it be a setting you could enable or a specific type of run & debug where you would specify that you want to stay in the interpreter?

Also @karthiknadig wondering if this would tie in at all to the no-config debugging since that would be right from the shell

[igiona]

Good to see some interest here :)

I would be more than happy with a config setting.
Many IDEs for other languages have the setting "stop on main when launched", this for python would kind of be the opposite version of that one "don't stop when exit"

[larsoner]

Would it be a setting you could enable or a specific type of run & debug where you would specify that you want to stay in the interpreter?

To me either way would work. One advantage of a separate command is then you can choose which one to use on the fly without needing to switch a config var. But in practice I personally would always just leave it set to "don't exit on completion" so it wouldn't affect my workflow much either way.