psutil provides different APIs that return multiple results (a list or a dict of elements), like psutil.Process.open_files() or psutil.net_connections(). It can happen that these API raise AccessDenied because of insufficient permissions, despite the fact that internally some information is collected (and discarded). Over the years there has been some demand to ignore AccessDenied and return a partial result instead:
The proposal is to identify for which APIs it make sense to do this, and either:
1) introduce an ignore_eperm (or similar) parameter to the function signatures that require it, e.g.
p = psutil.Process(pid)
files = p.open_files(ignore_eperm=True)
2) add a partial_result attribute to the AccessDenied instance, so that one can do:
p = psutil.Process(pid)
try:
files = p.open_files()
except psutil.AccessDenied as err:
files = err.partial_result
The first approach seems shorter and cleaner, but it requires changing the signature of multiple APIs (and the doc must reflect that).
The second approach appears more generic, but it's probably harder to understand for non-experts. Also, I guess it's too generic, because only certain APIs will set partial_result, so one may erroneously use the try/except idiom above and expect some result for an API which does not implement this contract.
It must be noted that also gopsutil project is puzzled by these sort of API design questions:
Problem
psutil provides different APIs that return multiple results (a list or a dict of elements), like
psutil.Process.open_files()orpsutil.net_connections(). It can happen that these API raiseAccessDeniedbecause of insufficient permissions, despite the fact that internally some information is collected (and discarded). Over the years there has been some demand to ignoreAccessDeniedand return a partial result instead:disk_io_counterson Windows)open_fileson Windows)open_fileson Windows)open_fileson Linux)In the past I explained why letting
AccessDeniedpropagate is a good thing (see https://github.com/giampaolo/psutil/issues/2124#issuecomment-1195925438). Nevertheless, the use case to be able to retrieve a partial result instead ofAccessDeniedappears justified.Proposal
The proposal is to identify for which APIs it make sense to do this, and either:
1) introduce an
ignore_eperm(or similar) parameter to the function signatures that require it, e.g.2) add a
partial_resultattribute to theAccessDeniedinstance, so that one can do:The first approach seems shorter and cleaner, but it requires changing the signature of multiple APIs (and the doc must reflect that). The second approach appears more generic, but it's probably harder to understand for non-experts. Also, I guess it's too generic, because only certain APIs will set
partial_result, so one may erroneously use thetry/exceptidiom above and expect some result for an API which does not implement this contract.It must be noted that also gopsutil project is puzzled by these sort of API design questions:
APIs
Potential API candidates are:
Process:
psutil.Process.children()psutil.Process.connections()psutil.Process.open_files()psutil.Process.parents()psutil.Process.threads()System:
psutil.disk_io_counters()psutil.disk_partitions()psutil.net_connections()psutil.net_io_counters()psutil.users()