homepage

Let's not allow the perfect to be the enemy of the good here.
The issue I reported is a very specific one: in Python 2.7, if you pass a long to sys.exit, then the value of the long is not used as the exit code. This is bad because functions like os.spawnv that return exit codes (that you might reasonably want to pass on to sys.exit) can return them as long.
My patch only proposes to address this one issue. In order to keep the impact as small as possible, I do not propose to make any other changes, or address any other problems.
But in the comments here people have brought up THREE other issues:
1. Alexander Belopolsky expresses the concern that "(int)PyLong_AsLong(value) can silently convert non-zero error code to zero."
This is not a problem introduced by my patch -- the current code is:
 exitcode = (int)PyInt_AsLong(value)
which has exactly the same problem (because PyIntObject stores its value as a long). So this concern (even if valid) is not a reason to reject my patch.
2. Ethan Furman wrote: "we need to protect against overflow from <long> to <int>"
But again, this is not a problem introduced by my patch. The current code says:
 exitcode = (int)PyInt_AsLong(value);
and my patch does not change this line. The possibility of this overflow is not a reason to reject my patch.
3. Alexander says, "Passing anything other than one of the os.EX_* constants to sys.exit() is a bad idea"
First, this is not a problem introduced by my patch. The existing code in Python 2.7 allows you to specify other exit codes. So this problem (if it is a problem) is not a reason to reject my patch.
Second, this claim is surely not right -- when a subprocess fails it often makes sense to pass on the exit code of the subprocess, whatever that is. This is exactly the use case that I mentioned in my original report (that is, passing on the exit code from os.spawnv to sys.exit).