sys.exit(object) is not accepted

[patrickdepinguin]

The Python documentation says:

https://docs.python.org/3/library/sys.html#sys.exit

sys.exit([arg])

    [...]

    The optional argument arg can be an integer giving the exit status (defaulting to zero), 
    or another type of object. [...] If another type of object is passed, None is equivalent to
    passing zero, and any other object is printed to stderr and results in an exit code of 1.

For example:

import sys
sys.exit(RuntimeError('oops'))

(which more commonly would be try...except RuntimeError as exc: [...]; sys.exit(exc) )

Output for mypy 1.18.2:

/tmp/test.py:3: error: Argument 1 to "exit" has incompatible type "RuntimeError"; expected "str | int | None"  [arg-type]

mypy only accepts str | int | None, as a result of issue #8513.

But, since this is valid Python code, I feel that mypy should accept it.

[srittau]

Cc @Akuli as author of #8513.

[Akuli]

Seems like we have three options:

1. Accept object: Not great, because you will not get a type checker error if you do sys.exit(some_list).
2. Accept str | int | Exception | None: Not great, because everyone who writes tests that catch a SystemExit will now wonder what the exception inside another exception is supposed to mean. These tests are not uncommon. You could, for example, write a main() function that uses sys.exit() for error handling and call it with different arguments in tests. And if SystemExit and sys.exit() are out of sync, there will be rare but confusing problems.
3. Change nothing: You will need to write sys.exit(str(exc)) instead of sys.exit(exc).

I'm tempted to think option 3 is the best here.

[patrickdepinguin]

But sys.exit(some_list) is perfectly valid. It is not just about exceptions.

any other object is printed to stderr and results in an exit code of 1.

Here are some examples of the behavior:

$ python -c 'import sys; sys.exit([4, 5])' ; echo $?
[4, 5]
1
$ python -c 'import sys; sys.exit(["foo", "bar"])'; echo $?
['foo', 'bar']
1
$ python -c 'import sys; sys.exit("oops")'; echo $?
oops
1
$ python -c 'import sys; import io ; sys.exit(io.StringIO())'; echo $?
<_io.StringIO object at 0x7f790861c700>
1
$ python -c 'import sys; import io ; sys.exit(15)'; echo $?
15

All this is valid Python, so why should a type checker not accept it?

[Akuli]

While sys.exit(some_list) is valid, it is almost surely not what you intended to do. A command-line that prints [4, 5] to stderr when it fails is not a good command line. Requiring these places be marked with # type: ignore seems perfect to me: you can still do whatever you want, you just need to mark "weird" things in the code with a # type: ignore comment.

The question is whether sys.exit(some_exception) is weird enough that you should mark it with # type: ignore. IMO it is, for two reasons:

1. The intent is to fail with the message of the error, and sys.exit(str(some_exception)) describes it better: fail (sys.exit) with the message (str) of the error (some_exception).
2. You are creating exception objects that contain other exception objects. This could be confusing for people who don't do sys.exit(some_exception).

Here's the nested exception thing:

>>> import sys
>>> try:
...     sys.exit(ValueError("oh no"))
... except SystemExit as e:
...     print(type(e), type(e.code))
... 
<class 'SystemExit'> <class 'ValueError'>