Treating RuntimeError as if it could take an errno is no good:

>>> try: signal.siginterrupt(32, 12345)
... except RuntimeError as e: print(e.errno)
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: (22, 'Invalid argument')

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
AttributeError: 'RuntimeError' object has no attribute 'errno'


Changing it breaks compatibility a bit but I think it's worth it.

I asked if I should use RuntimeError or OSError for the new signal functions (#8407) on python-dev. Georg Brandl answered:

"If it has an errno, it should be a subclass of EnvironmentError."

Patch: signal.signal() and signal.siginterrupt() raise an OSError, instead of a RuntimeError: OSError has an errno attribute.

> Patch: signal.signal() and signal.siginterrupt() raise an OSError,
> instead of a RuntimeError: OSError has an errno attribute.
> 
> ----------
> keywords: +patch
> Added file: http://bugs.python.org/file21939/signal_oserror.patch

Looks good to me.

New changeset b86b39211ef1 by Victor Stinner in branch 'default':
Issue #12011: signal.signal() and signal.siginterrupt() raise an OSError,
http://hg.python.org/cpython/rev/b86b39211ef1