The SystemExit exception, and consequently the sys.exit() function,  take a single parameter which is either an integer exit status for the process, or a message to print to stderr before exiting - in which case the exit status is implicitly 1.

In certain situations, it would be useful to pass both an exit status and a message. E.g. when argparse handles '--help', it wants to display a message and exit successfully (status 0). You may also use specific exit codes to indicate different kinds of failure.

Printing the message separately before raising SystemExit is not an entirely satisfactory subsitute, because the message attached to the exception is only printed if it is unhandled. E.g. for testing code that may raise SystemExit, it's useful to have the message as part of the exception.

I imagine that the trickiest bit of changing this would be ensuring as much backwards compatibility as possible. In particular, SystemExit exceptions have a 'code' attribute which can be either the exit status or the message.

The default handler writes the message of non-integer code to stderr, but in case of '--help', the message should be written to stdout. So this feature is not applicable for it. Are there other examples where this feature can be used?

In such cases it is better to write the message explicitly and call sys.exit() with the required exit code. For tests you can use contextlib.redirect_stderr() (or manually replace sys.stderr) to capture the stderr output.

You could add a flag in the exception to tell the default handler where to write the message. It would default to stderr.

This would make it possible to catch the exception before it was written out, and customize the behavior.