ecc75a0 to
94eb990
Compare
There was a problem hiding this comment.
It would be interesting to also implement the feature on Windows where "valid signals" is hard to guess for a Unix user. See signal_signal() of Modules/signalmodule.c for valid signals: I count 6 signals, 7 if SIGBREAK is also available.
There was a problem hiding this comment.
What do you think of testing len(s) < NSIG? Maybe len(s) <= NSIG?
There was a problem hiding this comment.
I'm not sure it's very useful.
There was a problem hiding this comment.
The purpose is to test if NSIG is consistent with sigfillset(), to check if something is really wrong on a platform. I would like to know if range(0, NSIG) miss some signals on some platforms :-)
|
You may also modify:
|
|
Thanks for the comments. You're right about Windows. I'll also fix asyncio and test.support. |
f505b3f to
1b694b3
Compare
|
Big +1 for this feature. Can you make it return a |
|
Frozen sets are nice if you want to hash them, otherwise I don't really see the point. |
6318e94 to
4b52abf
Compare
What's the point of being able to modify the returned set? ;) If you return a frozenset you can cache it (something that I would recommend doing in this PR anyways). This isn't a deal breaker, it's just that I would use a frozen set here. Overall LGTM. |
4b52abf to
ed4405c
Compare
ed4405c to
e7c0fd2
Compare
|
Other functions like |
|
First I wanted to get a list, but then I read the PR and I like reusing existing code :-) If someone wants an immutable type, it's very simple: frozenset(signal.valid_signals()). An immutable type might be justified if it was a module constant, but it's a function which creates a new object at each call, so IMHO a set is just fine. I don't want to modify other signal functions just to be pedantic. I like Antoine's rationale to use set in valid_signals(). |
https://bugs.python.org/issue33332