argparse.parse_args() exits the REPL

[NBoumakis]

Bug report

Bug description:

Hello!

Sorry if this has been reported before, but I didn't find something similar by looking through the issues here.

Consider this code snippet run in any kind of interactive console, e.g. the REPL or VS Code's new Native REPL:

import argparse

parser = argparse.ArgumentParser()
parser.add_argument("--test-arg")
parser.parse_args(["--test-arg"]) # No argument for --test-arg so as to raise the error

Because the default for ArgumentParser is exit_on_error=True, this will cause the interactive environment to exit. It is especially bad in VS Code because the cell simply hangs with the timer continuing the count, it is unable to terminate and upon closing/reopening the REPL the reported error is the very (not) helpful "Connection is closed".

Python's REPL also behaves similarly, exiting immediately with code 2. I think that the interactive console should continue running when an incorrect argument is passed in the evaluated code, or indeed if exit is not explicitly called by the user. Granted, the (to me, more) obvious behavior can be achieved by passing exit_on_error=False to ArgumentParser but this creates a potential for mistakes when moving between normal code and the REPL for, say, some debugging/testing.

I don't know what the sensible approach should be, however. When in a program this print-error-and-exit default is sensible, but when in interactive print-error-and-return is the expected behavior. Maybe take a step back and don't actually exit the REPL when exit is not explicitly called from the user, but only go back to the Read phase?

Apologies for the long message...

CPython versions tested on:

3.12, 3.14

Operating systems tested on:

Linux

[aisk]

I think calling parse_args inside a REPL is a bit unusual, the only realistic scenario is that the user is debugging their argparse code. In that case, if an error occurs when calling parse_args with invalid arguments but the process does not exit, the user might mistakenly believe that the same code would also not exit when run in a real program. That could lead to misunderstandings.

For this reason, I feel that giving the REPL behavior that differs from an actual program would introduce more problems. For users who really need to debug argparse inside the REPL, explicitly setting exit_on_error=False seems like a better solution.

[savannahostrowski]

Hey there! Agree with @aisk here. This is expected behavior and we can't make it environment-specific. The solution is to use exit_on_error=False.

[mpkocher]

For comparison, ipython's approach handles these cases gracefully.

In [2]: import argparse
   ...: 
   ...: parser = argparse.ArgumentParser()
   ...: parser.add_argument("--test-arg")
   ...: parser.parse_args(["--test-arg"]) # No argument for --test-arg so as to raise the error
usage: ipython [-h] [--test-arg TEST_ARG]
ipython: error: argument --test-arg: expected one argument
An exception has occurred, use %tb to see the full traceback.

SystemExit: 2

/Users/submarines/miniconda3/envs/core-314/lib/python3.14/site-packages/IPython/core/interactiveshell.py:3707: UserWarning: To exit: use 'exit', 'quit', or Ctrl-D.
  warn("To exit: use 'exit', 'quit', or Ctrl-D.", stacklevel=1)

In [3]: 

[NBoumakis]

calling parse_args inside a REPL is a bit unusual, the only realistic scenario is that the user is debugging their argparse code.

I agree with this part.

For this reason, I feel that giving the REPL behavior that differs from an actual program would introduce more problems. In that case, if an error occurs when calling parse_args with invalid arguments but the process does not exit, the user might mistakenly believe that the same code would also not exit when run in a real program. That could lead to misunderstandings

Yes, it could introduce a different set problems.

However, I think that library code exiting a REPL is a bit aggressive, especially for the unsuspecting. I would also argue that a REPL is mostly used for debugging in the first place, or at least that's what I usually do. Also, while this is IDE-specific, having to restart my editor because I tried parsing something incorrect seems... inefficient.

Also, this doesn't only apply to argparse. Any library code that has an exit call is problematic.

Here is a possible solution, IF we can detect that exit is called by the user. In REPL, catch the SystemExit exception and if not by the user directly, raise a WouldExitError or similar. Otherwise keep the usual approach. I have to check the code for possible performance overhead though. If REPL can be made to handle SystemExit internally, normal program execution should be unaffected.

[savannahostrowski]

Right, this is more of a REPL implementation choice than an argparse bug.

[NBoumakis]

For comparison, ipython's approach handles these cases gracefully.

In that case, it seems like an easy opportunity to become more compatible with other implementations

Right, this is more of a REPL implementation choice than an argparse bug.

You are correct, maybe I should have framed it differently