Like it says on the tin, it would be nice if strsignal(3) were added to the signal module.

This seems like a reasonable request to me. Do you want to propose a patch?

A dictionary, signal number -> signal name might be more friendly.

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.

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".

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'

Nice. However, strsignal() returns not just SIGINT, but "Interrupted" etc.

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.

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!

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()).

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

This is now pushed. Thank you Antoine!

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

Ned, this is why I'd like bpo-33048 to be solved :-) Having to rely on the buildbot fleet for bugfix iteration is not convenient at all.

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?

Should I submit a new PR for this?

Please do.

Done, #6085

As I said in the PR body, I can't test it myself, I don't have an OSX VM setup.

Ned, this is why I'd like bpo-33048 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!

New changeset 019f5b3 by Antoine Pitrou (Antoine Pietri) in branch 'master':
bpo-22674: fix test_strsignal on OSX (GH-6085)
019f5b3