This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Define EXIT_SUCCESS and EXIT_FAILURE constants in sys
Type: enhancement Stage: patch review
Components: Versions: Python 3.8
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: belopolsky Nosy List: Fat-Zer, belopolsky, berker.peksag, eamanu, edmundselliot@gmail.com, martin.panter, pitrou, rbcollins, scoder, serhiy.storchaka, skrah
Priority: normal Keywords: easy, patch

Created on 2015-04-24 15:47 by belopolsky, last changed 2022-04-11 14:58 by admin.

Files
File name Uploaded Description Edit
issue24053.patch belopolsky, 2015-04-24 16:29
Pull Requests
URL Status Linked Edit
PR 14773 open arnolddumas, 2019-07-14 10:26
Messages (37)
msg241949 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-04-24 15:47
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
msg241953 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-04-24 16:29
I am attaching a patch implementing these constants.  If this is well-received, I will add documentation.
msg241960 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2015-04-24 17:22
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.
msg241962 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-04-24 17:34
> 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.
msg241966 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2015-04-24 18:03
Sounds good, I have no objections.
msg241972 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-04-24 19:13
Aren't EXIT_SUCCESS and EXIT_FAILURE needed only for support VMS?
msg241978 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-04-24 19:59
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. :-)
msg242061 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2015-04-26 17:00
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 :-)
msg242126 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-04-27 16:56
> 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.
msg242129 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2015-04-27 17:05
> 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.
msg242130 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2015-04-27 17:18
I agree with Antoine -- all the exit codes should be in one place.
msg242131 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-04-27 17:23
> 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?
msg242132 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2015-04-27 17:31
Well, my favourite answer would be use sys.exit(0) and sys.exit(1), respectively (or raise SystemExit without or with an error message), as everyone is already doing right now. Since I don't really get the usability argument of adding those constants, it's hard for me to buy that they should sit close to sys.exit().
msg242133 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-04-27 17:35
Ethan> all the exit codes should be in one place.

Do you realize that os.EX_* codes are not available on Windows?  Having platform-independent EXIT_* codes next to posix-only EX_* codes will send the wrong message about their availability.
msg242135 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-04-27 17:43
Antoine> Since I don't really get the usability argument of adding those constants ..

If I am alone in finding exit(EXIT_FAILURE) clearer than exit(1), I should certainly drop my proposal.
msg242137 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2015-04-27 17:45
Well it would be clearer if not for the widely established knowledge (amongst most or all programming languages) that zero means success and non-zero means failure. So in this case I find it personally useless.
msg242139 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2015-04-27 17:47
I'm +0 on adding these. The only reason is that I've seen academic
code written by well-known researchers that used 1 for a successful
exit. :)

I'm not sure about the os module. These are C99 and not OS specific.
msg242141 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-04-27 18:18
Stefan> I've seen academic code written by well-known researchers
Stefan> that used 1 for a successful exit.

Thank you!  What I've seen more than once was exit(True) to indicate success where True is not necessarily a literal, but something like
len(results) > 0.
msg242142 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-04-27 18:27
This can be implemented as separate module on PyPI. No need to add these aliases for 0 and 1 to the stdlib.
msg242143 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-04-27 18:46
> This can be implemented as separate module on PyPI.

Sure!  Make them even less discoverable!

Let me try to state my motivations for adding these constants:

1. I find exit(EXIT_FAILURE) much clearer than exit(1). 
2. I want people to standardize on status=1 for a generic failure code.  I do see exit(-1) used as often as exit(1).
3. I want discourage people from using computed integer results as exit status.  For example,

# process files and store errors in a list
sys.exit(len(errors))  # bad - success for multiples of 256 errors
sys.exit(sys.EXIT_SUCCESS if not errors else sys.EXIT_FAILURE)  # good
msg242144 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2015-04-27 18:50
An entire PyPI module for two constants?

Change of heart, I'm okay with them going in sys, but only +0 on adding them.

This SO answer* has an interesting point to make about the nature of return codes and what their values should be; tl;dr - the convention should be between your program and the other program(s) you are trying communicate with.


* http://stackoverflow.com/a/8869000/208880
msg242145 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-04-27 18:56
> the convention should be between your program and the other program(s) you are trying communicate with.

This may be true in general, but Python stdlib sets the convention in its subprocess.check_call and subprocess.check_output methods.  These methods use 0=success convention.
msg242146 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2015-04-27 19:02
> I want people to standardize on status=1 for a generic failure code.

Why that? Multiple error codes can be used by the same program, depending on the kind of error.

> I want discourage people from using computed integer results as exit status.

Ok, that's the first good argument for this feature. Although I would encourage people raise an exception if they want to signify a failure, rather than simply change the error code.
msg242147 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2015-04-27 19:07
> 1. I find exit(EXIT_FAILURE) much clearer than exit(1). 

    import sys

    exit(sys.EXIT_FAILURE)

or

    import sys

    sys.exit(sys.EXIT_FAILURE)

don't look too clear to me. On the other hand, these constants may helpful to people who came from C world.

> 3. I want discourage people from using computed integer results as exit status.

Adding a FAQ entry or updating sys.exit() documentation would be more suitable to achieve the aim of this item. I wouldn't add two constants to the stdlib because of a bad programming practice.
msg242148 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2015-04-27 19:16
why not spell them "sys.exit.FAILURE" and "sys.exit.SUCCESS" ?
msg242149 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-04-27 19:17
>> I want people to standardize on status=1 for a generic failure code.

> Why that? Multiple error codes can be used by the same program, depending on the kind of error.

Antoine, please read what I write carefully before disagreeing.  I want "to standardize on status=1 for a **generic** failure code". Cooperating processes can certainly agree on other values for the specific failure modes.

What I really want to avoid is the use of -1 as a generic failure code, because it leads to a rather common error

rc = subprocess.call(..)
if rc < 0:
   raise Error   # never reached!
msg242150 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2015-04-27 19:19
How often you see EXIT_SUCCESS and EXIT_FAILURE in C code besides GNU tools that should support VMS? And even GNU tools usually use multiple error codes for different kinds of errors.

I think that these constants are rather unusual for C programmers.

I'm only -0 on adding these constants, not -1, because I'm sure they will be never used. But this will add a burden on the documentation and will confuse inexperienced users when they unexpectedly encounter with sys.exit(sys.EXIT_FAILURE) instead of sys.exit(1).
msg242151 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-04-27 19:23
> And even GNU tools usually use multiple error codes for different kinds of errors.

And how often do they not give them symbolic names?
msg242152 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2015-04-27 19:32
Actually, my guess is also that these constants will not be used. Not because they are not helpful, but because they'd only be available in Python 3.5+. Meaning that if you use them, your code won't work with long time supported CPython versions like 3.4 for the next decade or so.
msg242153 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-04-27 19:35
>  will confuse inexperienced users when they unexpectedly encounter with sys.exit(sys.EXIT_FAILURE) instead of sys.exit(1).

Are you serious?  I've seen senior programmers who thought that status < 0 means failure and status >= 0 means success.  Why would anyone who understands English would need to know what the numerical value of EXIT_FAILURE is to understand that status=EXIT_FAILURE means "failure"?


Not to mention that google returns a pageful of relevant links for "EXIT_FAILURE".
msg242154 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2015-04-27 19:55
> if you use them, your code won't work with long time
> supported CPython versions like 3.4 for the next decade or so.

This would be a generic argument against any new feature.  I don't think it is very compelling in this case.  For people who develop on a latest version. these constants will pop up in sys.<tab> autocompletion and they will likely use them.  If they need to support pre-3.5 versions,

try:
    from sys import exit, EXIT_FAILURE
except ImportError:
    from sys import exit
    EXIT_FAILURE = 1

is not a hard work-around.

You would say, why not just use EXIT_FAILURE = 1 to begin with?  To avoid Bob using EXIT_FAILURE = -1, Alice using EX_FAIL = 1 and Karl
giving up and using exit(1) in perpetuity.
msg247081 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2015-07-22 02:49
FWIW I have wondered in the past why these constants were missing. I would be more likely to use them when checking an exit status than when setting one. I typically do “raise SystemExit()” or “raise SystemExit('Error message')”, which implicitly sets the status.

My preference would be to put EXIT_SUCCESS and EXIT_FAILURE in the “os” module, next to the existing EX_ codes. But I guess the “sys” module would also work.
msg255473 - (view) Author: Robert Collins (rbcollins) * (Python committer) Date: 2015-11-27 18:15
@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.
msg331714 - (view) Author: Elliot Edmunds (edmundselliot@gmail.com) Date: 2018-12-12 18:58
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.
msg332526 - (view) Author: Emmanuel Arias (eamanu) * Date: 2018-12-26 02:15
Hi 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.
msg413528 - (view) Author: Golubev Alexander (Fat-Zer) Date: 2022-02-19 02:30
Any reasons the PR still not merged?
msg413537 - (view) Author: Stefan Behnel (scoder) * (Python committer) Date: 2022-02-19 07:18
> 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.
History
Date User Action Args
2022-04-11 14:58:16adminsetgithub: 68241
2022-02-19 08:03:29mark.dickinsonsetnosy: - mark.dickinson
2022-02-19 07:18:26scodersetmessages: + msg413537
2022-02-19 02:30:41Fat-Zersetnosy: + Fat-Zer
messages: + msg413528
2019-07-14 10:26:44arnolddumassetpull_requests: + pull_request14566
2018-12-26 02:15:21eamanusetnosy: + eamanu
messages: + msg332526
2018-12-12 20:26:54terry.reedysetnosy: - terry.reedy
2018-12-12 18:58:48edmundselliot@gmail.comsetnosy: + edmundselliot@gmail.com

messages: + msg331714
versions: + Python 3.8, - Python 3.5
2015-11-27 18:15:58rbcollinssetnosy: + rbcollins
messages: + msg255473
2015-07-22 02:49:06martin.pantersetmessages: + msg247081
2015-07-21 07:15:10ethan.furmansetnosy: - ethan.furman
2015-05-13 04:44:43martin.pantersetnosy: + martin.panter
2015-04-27 19:55:47belopolskysetmessages: + msg242154
2015-04-27 19:35:10belopolskysetmessages: + msg242153
2015-04-27 19:32:26scodersetmessages: + msg242152
2015-04-27 19:23:53belopolskysetmessages: + msg242151
2015-04-27 19:19:39serhiy.storchakasetmessages: + msg242150
2015-04-27 19:17:24belopolskysetmessages: + msg242149
2015-04-27 19:16:13scodersetnosy: + scoder
messages: + msg242148
2015-04-27 19:07:22berker.peksagsetnosy: + berker.peksag
messages: + msg242147
2015-04-27 19:02:14pitrousetmessages: + msg242146
2015-04-27 18:56:13belopolskysetmessages: + msg242145
2015-04-27 18:50:57ethan.furmansetmessages: + msg242144
2015-04-27 18:46:48belopolskysetmessages: + msg242143
2015-04-27 18:27:42serhiy.storchakasetmessages: + msg242142
2015-04-27 18:18:41belopolskysetmessages: + msg242141
2015-04-27 17:47:39skrahsetmessages: + msg242139
2015-04-27 17:45:03pitrousetmessages: + msg242137
2015-04-27 17:43:01belopolskysetmessages: + msg242135
2015-04-27 17:35:46belopolskysetmessages: + msg242133
2015-04-27 17:31:23pitrousetmessages: + msg242132
2015-04-27 17:23:22belopolskysetmessages: + msg242131
2015-04-27 17:18:55ethan.furmansetmessages: + msg242130
2015-04-27 17:05:02pitrousetmessages: + msg242129
2015-04-27 16:56:38belopolskysetmessages: + msg242126
2015-04-26 17:00:53pitrousetnosy: + pitrou
messages: + msg242061
2015-04-24 19:59:10belopolskysetmessages: + msg241978
2015-04-24 19:13:12serhiy.storchakasetmessages: + msg241972
2015-04-24 18:03:47ethan.furmansetmessages: + msg241966
2015-04-24 17:34:02belopolskysetmessages: + msg241962
2015-04-24 17:22:23ethan.furmansetmessages: + msg241960
2015-04-24 16:46:04belopolskysetnosy: + skrah
2015-04-24 16:32:11belopolskysetnosy: + terry.reedy, mark.dickinson, ethan.furman, serhiy.storchaka
2015-04-24 16:29:54belopolskysetfiles: + issue24053.patch
versions: + Python 3.5
messages: + msg241953

assignee: belopolsky
keywords: + easy, patch
stage: patch review
2015-04-24 15:47:49belopolskycreate