It strikes me as oddly dangerous that signal.signal() accepts callable handlers
of the wrong arity:
def timeout_cleanup():
...
signal.signal(signal.SIGALRM, timeout_cleanup) # I desire a TypeError
here
signal.alarm(PROCESS_TIMEOUT)
... time passes ...
TypeError: timeout_cleanup() takes 0 positional arguments but 2 were given
(Similar TypeError with different text under python 2.)
The downside to current behavior is that the coding error is revealed only
under certain conditions at runtime. In the example above, you don't know that
your seatbelt is defective until you need it.
Does anyone disagree with modifying signal.signal's behavior to raise a
TypeError when given a user-defined handler of the wrong arity? Any code
relying on this behavior is, IMO, contrived beyond plausibility. However, this
change might break code not yet known to be incorrect.
If no disagreements, patch or PEP?
-Mike
--
https://mail.python.org/mailman/listinfo/python-list
