exp_sig always assumes full POSIX compliance of the called executable

[languitar]

This issue is created after the discussions in #390 (comment)

The existing argument exp_sig for executors assumes full POSIX compliance of the called executable, because the expected return code is assumed to be the negation of the signal code. This assumes a cooperating executable being called that follows the convention of negating the received signal. In my case, I am running a Click executable with SimpleExecutor. Click, by default, always returns 1 on unhandled signals and in this case also the returncode is then 1. This can easily be verified with:

executed.py:

import time

import click


@click.command()
def hello():
    while True:
        time.sleep(10)


if __name__ == "__main__":
    hello()

executor.py:

from pathlib import Path
import subprocess
import sys
import time
import signal


proc = subprocess.Popen([sys.executable, Path(__file__).parent / "executed.py"])
with proc:
    time.sleep(2)
    print(f"sending {signal.SIGINT}")
    proc.send_signal(signal.SIGINT)

print(f"Returncode: {proc.returncode}")

❯ python executor.py 
sending 2

Aborted!
Returncode: 1

This is unfortunate because now I have to specify exp_sig=-1 to avoid the process execution exception, but the statement conveys a different meaning than what is actually done now.

I would propose to drop this argument (or to provide a second one for backwards-compatibility) that is called expected_returncode(s). This argument wouldn't do any negation magic. Something like SimpleExecutor("prog", expected_returncode=1) is also pretty easy to understand.

[fizyk]

I need to put that in my mind what I think I'll do:
We'll drop exp_sig alltogether.

If someone passes expected_returncode, we'll check for that, otherwise we'll attempt to guess it assuming POSIX compatibility. This will also benefit windows builds/attempts, I think 🤔