-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
leaking internal exeptions #1402
Comments
Yes, the |
Change was introduced in fe68b30. |
I'm afraid I'm not sure where this (original) name of the exception is coming from. Our >>> repr(psutil.Error())
'psutil.Error'
>>> repr(psutil.Error)
"<class 'psutil._exceptions.Error'>" We can override the repr of the class too using a metaclass, but that doesn't appear to solve the problem. In any case, I think we can simply rename |
I just moved the exceptions classes back into |
The reason setting If it's really important for it to be displayed as class Error(Exception):
__module__ = 'psutil' it's a bit of a hack but perfectly well-supported (especially since the class is imported into the top-level module namespace anyways). |
BTW the relevant logic for this can be seen in in >>> import traceback
>>> class Whatever(Exception): pass
...
>>> traceback.format_exception_only(Whatever, Whatever('oops'))
['Whatever: oops\n']
>>> class Whatever(Exception):
... __module__ = 'psutil'
...
>>> traceback.format_exception_only(Whatever, Whatever('oops'))
['psutil.Whatever: oops\n'] |
The problem is that with psutil (5.4.2) I'm getting some, internal, I guess, exceptions which shouldn't be visible externally, right? For example I'm getting psutil._exceptions.NoSuchProcess while documented is psutil.NoSuchProcess
The text was updated successfully, but these errors were encountered: