msg241949 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
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) * |
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) * |
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) * |
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) * |
Date: 2015-04-24 18:03 |
Sounds good, I have no objections.
|
msg241972 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2015-04-24 19:13 |
Aren't EXIT_SUCCESS and EXIT_FAILURE needed only for support VMS?
|
msg241978 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
Date: 2015-04-27 19:16 |
why not spell them "sys.exit.FAILURE" and "sys.exit.SUCCESS" ?
|
msg242149 - (view) |
Author: Alexander Belopolsky (belopolsky) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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.
|
|
Date |
User |
Action |
Args |
2022-04-11 14:58:16 | admin | set | github: 68241 |
2022-02-19 08:03:29 | mark.dickinson | set | nosy:
- mark.dickinson
|
2022-02-19 07:18:26 | scoder | set | messages:
+ msg413537 |
2022-02-19 02:30:41 | Fat-Zer | set | nosy:
+ Fat-Zer messages:
+ msg413528
|
2019-07-14 10:26:44 | arnolddumas | set | pull_requests:
+ pull_request14566 |
2018-12-26 02:15:21 | eamanu | set | nosy:
+ eamanu messages:
+ msg332526
|
2018-12-12 20:26:54 | terry.reedy | set | nosy:
- terry.reedy
|
2018-12-12 18:58:48 | edmundselliot@gmail.com | set | nosy:
+ edmundselliot@gmail.com
messages:
+ msg331714 versions:
+ Python 3.8, - Python 3.5 |
2015-11-27 18:15:58 | rbcollins | set | nosy:
+ rbcollins messages:
+ msg255473
|
2015-07-22 02:49:06 | martin.panter | set | messages:
+ msg247081 |
2015-07-21 07:15:10 | ethan.furman | set | nosy:
- ethan.furman
|
2015-05-13 04:44:43 | martin.panter | set | nosy:
+ martin.panter
|
2015-04-27 19:55:47 | belopolsky | set | messages:
+ msg242154 |
2015-04-27 19:35:10 | belopolsky | set | messages:
+ msg242153 |
2015-04-27 19:32:26 | scoder | set | messages:
+ msg242152 |
2015-04-27 19:23:53 | belopolsky | set | messages:
+ msg242151 |
2015-04-27 19:19:39 | serhiy.storchaka | set | messages:
+ msg242150 |
2015-04-27 19:17:24 | belopolsky | set | messages:
+ msg242149 |
2015-04-27 19:16:13 | scoder | set | nosy:
+ scoder messages:
+ msg242148
|
2015-04-27 19:07:22 | berker.peksag | set | nosy:
+ berker.peksag messages:
+ msg242147
|
2015-04-27 19:02:14 | pitrou | set | messages:
+ msg242146 |
2015-04-27 18:56:13 | belopolsky | set | messages:
+ msg242145 |
2015-04-27 18:50:57 | ethan.furman | set | messages:
+ msg242144 |
2015-04-27 18:46:48 | belopolsky | set | messages:
+ msg242143 |
2015-04-27 18:27:42 | serhiy.storchaka | set | messages:
+ msg242142 |
2015-04-27 18:18:41 | belopolsky | set | messages:
+ msg242141 |
2015-04-27 17:47:39 | skrah | set | messages:
+ msg242139 |
2015-04-27 17:45:03 | pitrou | set | messages:
+ msg242137 |
2015-04-27 17:43:01 | belopolsky | set | messages:
+ msg242135 |
2015-04-27 17:35:46 | belopolsky | set | messages:
+ msg242133 |
2015-04-27 17:31:23 | pitrou | set | messages:
+ msg242132 |
2015-04-27 17:23:22 | belopolsky | set | messages:
+ msg242131 |
2015-04-27 17:18:55 | ethan.furman | set | messages:
+ msg242130 |
2015-04-27 17:05:02 | pitrou | set | messages:
+ msg242129 |
2015-04-27 16:56:38 | belopolsky | set | messages:
+ msg242126 |
2015-04-26 17:00:53 | pitrou | set | nosy:
+ pitrou messages:
+ msg242061
|
2015-04-24 19:59:10 | belopolsky | set | messages:
+ msg241978 |
2015-04-24 19:13:12 | serhiy.storchaka | set | messages:
+ msg241972 |
2015-04-24 18:03:47 | ethan.furman | set | messages:
+ msg241966 |
2015-04-24 17:34:02 | belopolsky | set | messages:
+ msg241962 |
2015-04-24 17:22:23 | ethan.furman | set | messages:
+ msg241960 |
2015-04-24 16:46:04 | belopolsky | set | nosy:
+ skrah
|
2015-04-24 16:32:11 | belopolsky | set | nosy:
+ terry.reedy, mark.dickinson, ethan.furman, serhiy.storchaka
|
2015-04-24 16:29:54 | belopolsky | set | files:
+ issue24053.patch versions:
+ Python 3.5 messages:
+ msg241953
assignee: belopolsky keywords:
+ easy, patch stage: patch review |
2015-04-24 15:47:49 | belopolsky | create | |