-
-
Notifications
You must be signed in to change notification settings - Fork 30.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sys.addaudithook(hook) loops indefinitely on mismatch for hook #83363
Comments
When hook is not a compatible callable, addaudithook() will loop forever. At the minimum, a check for being callable should be executed. Preferably, a non-compatible (i.e. signature != [[str, tuple], Any]) hook callable should also be detected. >py
Python 3.8.1 (tags/v3.8.1:1b293b6, Dec 18 2019, 23:11:46) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.addaudithook(0)
error=10
Exception ignored in audit hook:
TypeError: 'int' object is not callable
File "<stdin>", line 0
SyntaxError: unknown parsing error
error=10
Exception ignored in audit hook:
TypeError: 'int' object is not callable
File "<stdin>", line 0
SyntaxError: unknown parsing error
error=10
Exception ignored in audit hook:
TypeError: 'int' object is not callable
File "<stdin>", line 0
SyntaxError: unknown parsing error
... etc. ... |
I think this is specific to the interactive prompt. Under normal circumstances, any error in calling the hook at the point where an event is being audited (which is immediate when using interactive mode) needs to propagate. Probably the best way to handle it is to call the hook with a new event indicating it's being added, but before it actually gets put into the list. A hook could then set up a different kind of loop, but it would be much harder to do it by accident. Perhaps "sys.addaudithook/self" with itself as an argument. We can't just use "sys.addaudithook" in case there are hooks that blindly abort this event (which there are, because I've written them ;) ). But this will at least make sure that the signature is correct and shouldn't send the interactive parser into a loop. |
|
I wrote too soon. Entering anything at the next line prints |
Right, IDLE doesn't call exec/compile until _after_ the code is submitted, while the regular prompt calls it first and passes stdin as the source file (which then does a buffered read). The loop occurs because the next action after an invalid input is to read another input, which is correct, it just doesn't (and cannot) detect the case where an error is raised _before_ the user presses Enter. |
As reported in # #125852 (which is a dupe of this), this issue causes PyREPL to exit both in Windows and Linux. Should I submit a simple PR adding a Edit: that won't work, as a callable can become non-callable after the check was done. But maybe checking at the time of calling the hook can work. |
Or as I suggested, call the hook before it gets added to the list. If it's not callable, you get an error immediately. If it changes behaviour later, well, that's what the "we're all consenting adults here" rule is for (i.e. don't change behaviour later unless you want to break yourself). |
Currently, a hook raising an exception fails silently (and stops calling of hooks added later), right? If so, would that behavior change (don't add the hook if it raises any exception) or would we only skip adding it if the exception indicates it's not callable? Wouldn't it be simpler to check whether it's callable at adding time, if we don't care whether it's always callable? |
That's what I said. Make |
Sorry, I meant checking |
A hook that has side effects for an unknown event is already in a decent amount of trouble, but finding that out immediately (especially if it's an error) is much more helpful, and will only be found by actually calling it. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: