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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
Date: 2018-03-12 13:43 |
This is now pushed. Thank you Antoine!
|
msg313660 - (view) |
Author: Ned Deily (ned.deily) * |
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) * |
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) * |
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) * |
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) * |
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
|
|
Date |
User |
Action |
Args |
2022-04-11 14:58:09 | admin | set | github: 66864 |
2018-03-12 19:03:28 | pitrou | set | status: open -> closed resolution: fixed stage: patch review -> resolved |
2018-03-12 19:03:17 | pitrou | set | messages:
+ msg313679 |
2018-03-12 17:41:18 | ned.deily | set | messages:
+ msg313670 |
2018-03-12 16:33:33 | antoine.pietri | set | messages:
+ msg313667 |
2018-03-12 16:32:49 | antoine.pietri | set | stage: needs patch -> patch review pull_requests:
+ pull_request5846 |
2018-03-12 16:25:11 | pitrou | set | messages:
+ msg313665 |
2018-03-12 16:24:30 | antoine.pietri | set | messages:
+ msg313663 |
2018-03-12 16:09:51 | pitrou | set | messages:
+ msg313661 |
2018-03-12 16:07:03 | ned.deily | set | status: closed -> open
nosy:
+ ned.deily messages:
+ msg313660
resolution: fixed -> (no value) stage: resolved -> needs patch |
2018-03-12 13:43:19 | pitrou | set | nosy:
+ pitrou messages:
+ msg313650
|
2018-03-12 13:42:57 | pitrou | set | status: open -> closed stage: patch review -> resolved resolution: fixed versions:
+ Python 3.8, - Python 3.5 |
2018-03-07 18:31:53 | antoine.pietri | set | messages:
+ msg313390 |
2018-03-07 18:29:44 | antoine.pietri | set | stage: patch review pull_requests:
+ pull_request5784 |
2018-03-07 00:06:16 | cvrebert | set | nosy:
+ cvrebert
|
2017-10-13 13:07:27 | vstinner | set | messages:
+ msg304335 title: strsignal() missing from signal module -> RFE: Add signal.strsignal(): string describing a signal |
2017-10-12 21:45:20 | antoine.pietri | set | nosy:
+ antoine.pietri messages:
+ msg304290
|
2014-10-26 12:26:40 | vajrasky | set | files:
+ strsignal.patch
nosy:
+ vajrasky messages:
+ msg230026
keywords:
+ patch |
2014-10-20 17:36:23 | georg.brandl | set | messages:
+ msg229738 |
2014-10-20 12:52:59 | vstinner | set | nosy:
+ vstinner messages:
+ msg229726
|
2014-10-20 07:17:28 | georg.brandl | set | nosy:
+ georg.brandl messages:
+ msg229717
|
2014-10-19 20:56:17 | r.david.murray | set | messages:
+ msg229698 |
2014-10-19 20:51:22 | benjamin.peterson | set | nosy:
+ benjamin.peterson messages:
+ msg229697
|
2014-10-19 20:43:54 | r.david.murray | set | nosy:
+ r.david.murray
messages:
+ msg229695 versions:
+ Python 3.5, - Python 3.4 |
2014-10-19 19:12:54 | Dolda2000 | create | |