classification
Title: RFE: Add signal.strsignal(): string describing a signal
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.8
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Dolda2000, antoine.pietri, benjamin.peterson, cvrebert, georg.brandl, ned.deily, pitrou, r.david.murray, vajrasky, vstinner
Priority: normal Keywords: patch

Created on 2014-10-19 19:12 by Dolda2000, last changed 2018-03-12 19:03 by pitrou. This issue is now closed.

Files
File name Uploaded Description Edit
strsignal.patch vajrasky, 2014-10-26 12:26 review
Pull Requests
URL Status Linked Edit
PR 6017 merged antoine.pietri, 2018-03-07 18:29
PR 6085 merged antoine.pietri, 2018-03-12 16:32
Messages (19)
msg229691 - (view) Author: (Dolda2000) Date: 2014-10-19 19:12
Like it says on the tin, it would be nice if strsignal(3) were added to the signal module.
msg229695 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-10-19 20:43
This seems like a reasonable request to me.  Do you want to propose a patch?
msg229697 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2014-10-19 20:51
A dictionary, signal number -> signal name might be more friendly.
msg229698 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2014-10-19 20:56
Yeah, the thinnest possible exposure of the strsignal API wouldn't really be that sensible for Python.  But making the OS information available *somehow* makes sense.
msg229717 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2014-10-20 07:17
Is it possible to determine the range of signal numbers?  Otherwise it would be a guessing game where to stop querying when filling up the dictionary.

A problem is also that if the signal number is not valid, the return value of strsignal() is unspecified, *and* there is no way to check for this situation because "no errors are defined".
msg229726 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2014-10-20 12:52
I don't think that a strsignal() is required, signals now have a name attribute!

Python 3.5.0a0 (default:07ae7bc06af0, Oct 16 2014, 09:46:01) 
>>> import signal
>>> signal.SIGINT
<Signals.SIGINT: 2>
>>> signal.SIGINT.name
'SIGINT'
msg229738 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2014-10-20 17:36
Nice. However, strsignal() returns not just SIGINT, but "Interrupted" etc.
msg230026 - (view) Author: Vajrasky Kok (vajrasky) * Date: 2014-10-26 12:26
Here is the preliminary patch. It's a thin wrapper of strsignal.

Some issues and things:
1. About Benjamin Peterson's request, what is the name of the dictionary supposed to be? Is everyone okay with Benjamin's suggestion?

2. About George Brandl's question: "Is it possible to determine the range of signal numbers?" We have a heuristic algorithm:

#ifndef NSIG
# if defined(_NSIG)
#  define NSIG _NSIG            /* For BSD/SysV */
# elif defined(_SIGMAX)
#  define NSIG (_SIGMAX + 1)    /* For QNX */
# elif defined(SIGMAX)
#  define NSIG (SIGMAX + 1)     /* For djgpp */
# else
#  define NSIG 64               /* Use a reasonable default value */
# endif
#endif

if (sig_num < 1 || sig_num >= NSIG) {
        PyErr_SetString(PyExc_ValueError,
                        "signal number out of range");
        return NULL;
}

3. For the unknown signal, what is the description should be? "Unknown signal" like c function returns or None?

4. What is the name of the function that wrap strsignal should be? I use strsignal for now. I just don't think it is appropriate.
msg304290 - (view) Author: Antoine Pietri (antoine.pietri) * Date: 2017-10-12 21:45
Hey everyone,

We would like to have that feature for a project where we have to use ctypes to achieve that. I don't know the answers to vajrasky's questions but I just wanted to chime in to say having this feature would be greatly appreciated. I can also work on the code if you need any help.

Thanks!
msg304335 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-10-13 13:07
> 3. For the unknown signal, what is the description should be? "Unknown signal" like c function returns or None?

Hum, Linux returns "Unknown signal 12345". I propose to use this behaviour on all platforms (which provide strsignal()).
msg313390 - (view) Author: Antoine Pietri (antoine.pietri) * Date: 2018-03-07 18:31
I updated Vajrasky's patch to rebase it onto master, use the clinic argument parser and improve the docs. I made a PR on GitHub so the review can be easier than a patch.

I left a Co-Authored-By field so I'm not stealing the ownership of this patch :-P
msg313650 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2018-03-12 13:43
This is now pushed.  Thank you Antoine!
msg313660 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-03-12 16:07
test_strsignal is failing on macOS.

======================================================================
FAIL: test_strsignal (test.test_signal.PosixTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/nad/Projects/PyDev/active/dev/3x/source/Lib/test/test_signal.py", line 61, in test_strsignal
    self.assertEqual(signal.strsignal(signal.SIGINT), "Interrupt")
AssertionError: 'Interrupt: 2' != 'Interrupt'
- Interrupt: 2
?          ---
+ Interrupt


Also:
http://buildbot.python.org/all/#/builders/14/builds/779/steps/4/logs/stdio
http://buildbot.python.org/all/#/builders/93/builds/435/steps/4/logs/stdio
msg313661 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2018-03-12 16:09
Ned, this is why I'd like issue33048 to be solved :-) Having to rely on the buildbot fleet for bugfix iteration is not convenient at all.
msg313663 - (view) Author: Antoine Pietri (antoine.pietri) * Date: 2018-03-12 16:24
Yes, sorry, the issue is that we decided with pitrou to remove the osx specific handling.

The fix should be:

diff --git a/Lib/test/test_signal.py b/Lib/test/test_signal.py
index fbb12a5b67..ae0351e992 100644
--- a/Lib/test/test_signal.py
+++ b/Lib/test/test_signal.py
@@ -58,8 +58,10 @@ class PosixTests(unittest.TestCase):
         self.assertEqual(signal.getsignal(signal.SIGHUP), hup)
 
     def test_strsignal(self):
-        self.assertEqual(signal.strsignal(signal.SIGINT), "Interrupt")
-        self.assertEqual(signal.strsignal(signal.SIGTERM), "Terminated")
+        self.assertTrue(signal.strsignal(signal.SIGINT)
+                        .startswith("Interrupt"))
+        self.assertTrue(signal.strsignal(signal.SIGTERM)
+                        .startswith("Terminated"))
 
     # Issue 3864, unknown if this affects earlier versions of freebsd also
     def test_interprocess_signal(self):


Should I submit a new PR for this?
msg313665 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2018-03-12 16:25
> Should I submit a new PR for this?

Please do.
msg313667 - (view) Author: Antoine Pietri (antoine.pietri) * Date: 2018-03-12 16:33
Done, https://github.com/python/cpython/pull/6085

As I said in the PR body, I can't test it myself, I don't have an OSX VM setup.
msg313670 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-03-12 17:41
> Ned, this is why I'd like issue33048 to be solved :-) Having to rely on the buildbot fleet for bugfix iteration is not convenient at all.

I want to see it solved, too. :-)  But there are other core-devs out there who are in a better position to solve it at the moment; it's not particularly a macOS problem; it's a problem with using Homebrew and Travis, neither one of which I'm all that familiar with and which others have set up.  And I'm in the middle of trying to get some releases and other stuff out the door.  So, I'm not going to be able to spend time on it right now.  Sorry!
msg313679 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2018-03-12 19:03
New changeset 019f5b3e9e4c2a1297580483c3d5a5a10bddb93b by Antoine Pitrou (Antoine Pietri) in branch 'master':
bpo-22674: fix test_strsignal on OSX (GH-6085)
https://github.com/python/cpython/commit/019f5b3e9e4c2a1297580483c3d5a5a10bddb93b
History
Date User Action Args
2018-03-12 19:03:28pitrousetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2018-03-12 19:03:17pitrousetmessages: + msg313679
2018-03-12 17:41:18ned.deilysetmessages: + msg313670
2018-03-12 16:33:33antoine.pietrisetmessages: + msg313667
2018-03-12 16:32:49antoine.pietrisetstage: needs patch -> patch review
pull_requests: + pull_request5846
2018-03-12 16:25:11pitrousetmessages: + msg313665
2018-03-12 16:24:30antoine.pietrisetmessages: + msg313663
2018-03-12 16:09:51pitrousetmessages: + msg313661
2018-03-12 16:07:03ned.deilysetstatus: closed -> open

nosy: + ned.deily
messages: + msg313660

resolution: fixed -> (no value)
stage: resolved -> needs patch
2018-03-12 13:43:19pitrousetnosy: + pitrou
messages: + msg313650
2018-03-12 13:42:57pitrousetstatus: open -> closed
stage: patch review -> resolved
resolution: fixed
versions: + Python 3.8, - Python 3.5
2018-03-07 18:31:53antoine.pietrisetmessages: + msg313390
2018-03-07 18:29:44antoine.pietrisetstage: patch review
pull_requests: + pull_request5784
2018-03-07 00:06:16cvrebertsetnosy: + cvrebert
2017-10-13 13:07:27vstinnersetmessages: + msg304335
title: strsignal() missing from signal module -> RFE: Add signal.strsignal(): string describing a signal
2017-10-12 21:45:20antoine.pietrisetnosy: + antoine.pietri
messages: + msg304290
2014-10-26 12:26:40vajraskysetfiles: + strsignal.patch

nosy: + vajrasky
messages: + msg230026

keywords: + patch
2014-10-20 17:36:23georg.brandlsetmessages: + msg229738
2014-10-20 12:52:59vstinnersetnosy: + vstinner
messages: + msg229726
2014-10-20 07:17:28georg.brandlsetnosy: + georg.brandl
messages: + msg229717
2014-10-19 20:56:17r.david.murraysetmessages: + msg229698
2014-10-19 20:51:22benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg229697
2014-10-19 20:43:54r.david.murraysetnosy: + r.david.murray

messages: + msg229695
versions: + Python 3.5, - Python 3.4
2014-10-19 19:12:54Dolda2000create