signal.signal handler arity check - PEP?
Mike Pomraning
mjp at pilcrow.madison.wi.us
Wed Dec 17 12:12:57 EST 2014
More information about the Python-list mailing list
Wed Dec 17 12:12:57 EST 2014
- Previous message (by thread): smptplib problem SMTPRecipientsRefused for emails with ! exclamation mark in local portion of email
- Next message (by thread): Is there a way to schedule my script?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): smptplib problem SMTPRecipientsRefused for emails with ! exclamation mark in local portion of email
- Next message (by thread): Is there a way to schedule my script?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list