Repository navigation
Define EXIT_SUCCESS and EXIT_FAILURE constants in sys #68241
Description
Activity
Python defines some BSDish exit codes in the os module:
EX_CANTCREAT = 73 EX_CONFIG = 78 EX_DATAERR = 65 EX_IOERR = 74 EX_NOHOST = 68 EX_NOINPUT = 66 EX_NOPERM = 77 EX_NOUSER = 67 EX_OK = 0 EX_OSERR = 71 EX_OSFILE = 72 EX_PROTOCOL = 76 EX_SOFTWARE = 70 EX_TEMPFAIL = 75 EX_UNAVAILABLE = 69 EX_USAGE = 64
but these are documented as only available on UNIX and may not be portable across all flavors.
POSIX [1] and C99 defines EXIT_SUCCESS and EXIT_FAILURE constants. I propose adding those to sys.
Having these constants in sys will make them more discoverable because they will be next to sys.exit().
[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/exit.html
I am attaching a patch implementing these constants. If this is well-received, I will add documentation.
Where are EXIT_FAILURE and EXIT_SUCCESS defined?
And we should probably call them EX_FAILURE and EX_SUCESS to match what's already there.
Where are EXIT_FAILURE and EXIT_SUCCESS defined?
In C stdlib:
$ grep EXIT_ /usr/include/stdlib.h #define EXIT_FAILURE 1 #define EXIT_SUCCESS 0
we should probably call them EX_FAILURE and EX_SUCESS to match what's already there.
No. EX_ macros come from a non-standard sysexits.h header. Python stdlib traditionally does not change the spelling of the constants that
come from C libraries or standards.Even in the absence of POSIX and C99 standards, I would prefer EXIT_ prefix over EX_ for clarity. "EX" does not clearly mean "exit", it may stand for "exception", "execution", "example" etc.
Sounds good, I have no objections.
Aren't EXIT_SUCCESS and EXIT_FAILURE needed only for support VMS?
I would say, they are there to support *humans*. I am not aware of any human language where "success" is spelled 0. (1 is a failing mark in some schools - so there is a precedent for that. :-)
Those should be in the os module, not in sys. The os module is for interfaces to the operating system, while the sys module is for Python-specific stuff.
As for the point of adding them, I don't find them useful, but I won't oppose it either :-)
Those should be in the os module, not in sys.
I disagree. The whole point of this proposal is to have platform-independent status codes available next to the sys.exit() function.
We already have over a dozen BSDish exit codes in os that are hardly ever used.
We already have over a dozen BSDish exit codes in os that are hardly
ever used.Then precisely, those new codes should go in the os module as well.
I agree with Antoine -- all the exit codes should be in one place.
Then precisely, those new codes should go in the os module as well.
What is your logic? Having os.EX_ codes in os does not help as far as sys.exit() is concerned: no-one is using them and they are not available on all platforms. If we add EXIT_FAILURE and EXIT_SUCCESS to os now, we will only create confusion: should I use os.EX_OK or os.EXIT_SUCCESS?
Note that sys.exit() is different from os._exit(). It may not even result in termination of the interpreter. Why should users of sys.exit() be required to import os if they want to indicate a failure?
20 remaining items
@serhiy, EXIT_FAILURE is used in Python's C code itself (just once admittedly, and then we use 0 sometimes for success and sometimes for errors, and then 1 for errors... aiee.)
FWIW to the extent that folk want to write posix code in Python, I'm all for helping them, I find the amount of help this will be to be hard to assess. There is some code to adding the constants in documentation and learning surface area.
Right now we don't document all the ways Python can interact with exit codes, and I suspect thats actually a bigger burden than writing the code to generate any given code.
eedmunds commented
on Dec 12, 2018 eedmundsmannequinMannequinI have personally come across situations where I am calling a Python script from a C program and would like to check the exit codes of the script, and have had to write sys.exit(1) and sys.exit(0) in Python, and compared them to EXIT_SUCCESS/EXIT_FAILURE in C. It would have been easy to introduce a bug where I returned the wrong exit code, so I was hoping they would have been implemented in sys.
It seems like a no-brainer to add these, they reduce magic number use and improve the accessibility of Python to people coming from C. I would love to add these if everyone is OK with it.
eamanu commented
on Dec 26, 2018 eamanumannequinMannequinHi Elliot!
It seems like a no-brainer to add these, they reduce magic number use and improve the accessibility of Python to people coming from C. I would love to add these if everyone is OK with it.
Sound great. But IMO I think that this can be solved doing:
EXIT_FAILURE = 1 EXIT_SUCCESS = 0 sys.exit(EXIT_SUCCES)
And what is the difference between EX_OK and EXIT_SUCCESS? both values are 0.
BTW, I think this is a good improve and more for C coder.
I recommend you mmake the PR.
Fat-Zer commented
on Feb 19, 2022 Fat-ZermannequinMannequinAny reasons the PR still not merged?
Any reasons the PR still not merged?
There was dissent about whether these constants should be added or not. It doesn't help to merge a PR that is not expected to provide a benefit.
If I am alone in finding exit(EXIT_FAILURE) clearer than exit(1), I should certainly drop my proposal.
@abalkin Currently,
sys.exit(message)chooses theEXIT_SUCCESS/EXIT_FAILUREcode depending on whether the message isNone.Is
sys.exit(EXIT_SUCCESS)/sys.exit(EXIT_FAILURE)still relevant then?Is sys.exit(EXIT_SUCCESS)/sys.exit(EXIT_FAILURE) still relevant then?
Maybe one doesn't want to give an actual message but just control the exit status?
Also I have for example code, where depending on what happens I set some
exit_statusvariable. But I don't e.g. just pass that tosys.exit()in the end, but have anotherifbefore, that would want to check something likeexit_status != EXIT_SUCCESSand do extra things depending on that.
So I think one really "needs" the symbol.Also, these are really standardised system symbols, so people might want to use them for checking exit statuses of subprocesses and not just as part of
sys.exit().As for the discussion about
sysvs.os... AFAIU POSIX, onlyEXIT_SUCCESSis defined to be a fixed value (0)... so I'd interpret that asEXIT_FAILUREbeing potentially platform-dependent.
Oh and it was mentioned thatEX_OKwould be documented as UNIX-only, but current documentation seems to say "Availability: Unix, Windows.".Hmm... let's be pragmatic here.
sys.exit(0)is known to exit with success.sys.exit(non-zero integer)is known to be a failure exit. Which exit code you choose is on you: many CLI utilities can actually return different error codes depending on the actual error.Since all concrete use cases are well-served already, I will close this isuue.
I read through the whole issue, and I am not convinced that not defining these codes make sense.
sys.exit(0) is known to exit with success.
This is obviously true. Nevertheless, I'm currently reviewing code that contains a function which is meant to be invoked as entrypoint using
[project.scripts]inpyproject.toml. When reading that function, it containsreturn 0andreturn 1statements. As that code is actually correct, it returns 0 for success and 1 for failure. But, as you might already have noticed, the code does not containsys.exit(0), which is well-known to be "OK", orsys.exit(1)which is well-known to mean "some generic failure happened, but the author of this tool didn't bother to define specific exit codes".
In my not so humble oppinion,return EXIT_SUCCESSandreturn EXIT_FAILUREconvey a lot more meaning than returning the magic numbers 0 and 1.If we are looking at integral function return values to indicate operation status there are many conventions:
- System calls like read, in which negative is bad and positive is good (positive values usually indicating some kind of count)
- Process exit codes in which non-zero is bad and 0 is good
- Standard system calls, in which -1 is bad and 0 is good, which actually happens to be consistent with the contract of read and the contract of exit codes
- Ad-Hoc booleans in which 0 is False (which is bad) and 1 is True (which is good)
Just reading
return EXIT_SUCCESSorreturn EXIT_FAILUREconveys two important messages:- The return code is meant to be a process exit code
EXIT_SUCCESSmeans "good" in this situation.
While of course you might argue that you might want more than 1 "bad" exit code, the convention of using "1" as generic error code if no special convention exists has been around since more than 40 years, and will be around as long as C exists. As these constants are not just POSIX, but even C99, they should be available on nearly any platform around today, which sets them apart from
EX_..., and is a good reason to put them intosysinstead ofos, because the availability of these constants is not meant to be OS specific.Suggesting to reopen this issue, because I would have filed a new one if this issue didn't exist.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: