Repository navigation
Define EXIT_SUCCESS and EXIT_FAILURE constants in sys #68241
Description
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:
assignee = 'https://github.com/abalkin'
closed_at = None
created_at = <Date 2015-04-24.15:47:49.923>
labels = ['easy', 'type-feature', '3.8']
title = 'Define EXIT_SUCCESS and EXIT_FAILURE constants in sys'
updated_at = <Date 2022-02-19.08:03:29.457>
user = 'https://github.com/abalkin'bugs.python.org fields:
activity = <Date 2022-02-19.08:03:29.457>
actor = 'mark.dickinson'
assignee = 'belopolsky'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2015-04-24.15:47:49.923>
creator = 'belopolsky'
dependencies = []
files = ['39197']
hgrepos = []
issue_num = 24053
keywords = ['patch', 'easy']
message_count = 37.0
messages = ['241949', '241953', '241960', '241962', '241966', '241972', '241978', '242061', '242126', '242129', '242130', '242131', '242132', '242133', '242135', '242137', '242139', '242141', '242142', '242143', '242144', '242145', '242146', '242147', '242148', '242149', '242150', '242151', '242152', '242153', '242154', '247081', '255473', '331714', '332526', '413528', '413537']
nosy_count = 11.0
nosy_names = ['belopolsky', 'pitrou', 'scoder', 'rbcollins', 'skrah', 'berker.peksag', 'martin.panter', 'serhiy.storchaka', 'eamanu', 'edmundselliot@gmail.com', 'Fat-Zer']
pr_nums = ['14773']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue24053'
versions = ['Python 3.8']
Activity
abalkin commentedon Apr 24, 2015
Python defines some BSDish exit codes in the os module:
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
abalkin commentedon Apr 24, 2015
I am attaching a patch implementing these constants. If this is well-received, I will add documentation.
ethanfurman commentedon Apr 24, 2015
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.
abalkin commentedon Apr 24, 2015
In C stdlib:
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.
ethanfurman commentedon Apr 24, 2015
Sounds good, I have no objections.
serhiy-storchaka commentedon Apr 24, 2015
Aren't EXIT_SUCCESS and EXIT_FAILURE needed only for support VMS?
abalkin commentedon Apr 24, 2015
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. :-)
pitrou commentedon Apr 26, 2015
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 :-)
abalkin commentedon Apr 27, 2015
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.
pitrou commentedon Apr 27, 2015
Then precisely, those new codes should go in the os module as well.
ethanfurman commentedon Apr 27, 2015
I agree with Antoine -- all the exit codes should be in one place.
abalkin commentedon Apr 27, 2015
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
rbtcollins commentedon Nov 27, 2015
@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 commentedon Dec 12, 2018
I 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 commentedon Dec 26, 2018
Hi Elliot!
Sound great. But IMO I think that this can be solved doing:
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 commentedon Feb 19, 2022
Any reasons the PR still not merged?
scoder commentedon Feb 19, 2022
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.
arhadthedev commentedon May 16, 2022
@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?calestyo commentedon Jul 26, 2023
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 that
EX_OKwould be documented as UNIX-only, but current documentation seems to say "Availability: Unix, Windows.".pitrou commentedon Jul 26, 2023
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.
karcherm commentedon Oct 5, 2026
I read through the whole issue, and I am not convinced that not defining these codes make sense.
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:
Just reading
return EXIT_SUCCESSorreturn EXIT_FAILUREconveys two important messages: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.