You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Need a way to subscribe to DriverWarning as events with a callback #2088
With warnings.warn, if users have to asynchronously process driver warnings, then they need to override the warnings.showwarning function with a custom handler which would process driver warnings differently. This implies a global override, more things for users to maintain and a possibility of not handling certain other warnings in the application correctly. Would be good to have a warning event mechanism built into driver session which the users can subscribe to, by passing a callback function. This event mechanism can co-exist with the current warnings.warn. This way, users can adopt whatever approach makes sense for the application.
ie:
if they want to raise exceptions for warnings, then they can simply do warnings.simplefilter("error", DriverWarning)
if they want to asynchronously handle warnings without stopping the execution flow, then they can do session.warning_event.subscribe(driverwarninghandler(DriverWarning)) and define
def driverwarninghandler(DriverWarning):
<log to file, set a flag, push to a queue, raise few warnings and ignore others, etc>
Along with thread-safe override option, it would help if warnings.showwarning could be overridden for a specific class of warning, even if its going to be a global override. That would work for the use case I've mentioned and would not need us to have an additional warning event mechanism in nimi-python. Could not find any issue/discussion already for this. Created a discussion topic.
@vnktshr21 Is asynchronous handling actually useful?
Do you know of specific warnings where it's okay to handle things that way?
When I think of warnings, I think of things like the PLL coming unlocked and possibly invalidating data. That's not the sort of thing where I'd want to keep going.
Activity
bkeryan commentedon Mar 26, 2025
It sounds like
warnings.catch_warnings()may be thread-safe in future versions of Python:https://discuss.python.org/t/thread-safe-warning-filters/76074/10
vnktshr21 commentedon Mar 27, 2025
Along with thread-safe override option, it would help if warnings.showwarning could be overridden for a specific class of warning, even if its going to be a global override. That would work for the use case I've mentioned and would not need us to have an additional warning event mechanism in nimi-python. Could not find any issue/discussion already for this. Created a discussion topic.
ni-jfitzger commentedon May 28, 2025
@vnktshr21 Is asynchronous handling actually useful?
Do you know of specific warnings where it's okay to handle things that way?
When I think of warnings, I think of things like the PLL coming unlocked and possibly invalidating data. That's not the sort of thing where I'd want to keep going.