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
# Motivation
Currently core interface can be use to register and call listener on
specific internal events with
- `core.on` to register an event
- `core.dispatch` to call listener on a specific event
`core.dispatch` returns a tuple of lists containing results or possible
exceptions of all listeners in the order they were registered. This is
difficult to use, as we have to properly check the lists length and
guess the registration order in case of several listeners. Using
`[0][0]` to access result is not meaningful nor without a risk of
errors.
# Proposition of this PR
- `core.on` to register an event with an additional optional name
- `core.dispatch` to call listener on a specific event will return a
EventResultDict that can be used like that:
```python
# some file
core.on("my_event", listener_function, "my_name")
# some other file
core.on("my_event", listener_function_2, "my_second_name")
# some other listener, but you don't care about the return value, so no need to set a name
core.on("my_event", listener_function_3)
# in another file
res = core.dispatch("my_event")
if res.my_name:
result = res.my_name.value
...
# optional error handling
else:
if res.my_name.response_type == core.ResultType.RESULT_UNDEFINED:
log.debug("listener my_name was not registered on my_event")
elif res..my_name.response_type == core.ResultType.RESULT_EXCEPTION:
log.debug("listener my_name on my_event raised exception %s", res.my_name.exception)
# you can also just simply get the returned value of the listener.
# In case of an error, this is set to None anyway, so it never breaks.
second_name = res.my_second_name.value
```
## Checklist
- [x] Change(s) are motivated and described in the PR description.
- [x] Testing strategy is described if automated tests are not included
in the PR.
- [x] Risk is outlined (performance impact, potential for breakage,
maintainability, etc).
- [x] Change is maintainable (easy to change, telemetry, documentation).
- [x] [Library release note
guidelines](https://ddtrace.readthedocs.io/en/stable/releasenotes.html)
are followed. If no release note is required, add label
`changelog/no-changelog`.
- [x] Documentation is included (in-code, generated user docs, [public
corp docs](https://github.com/DataDog/documentation/)).
- [x] Backport labels are set (if
[applicable](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting))
## Reviewer Checklist
- [x] Title is accurate.
- [x] No unnecessary changes are introduced.
- [x] Description motivates each change.
- [x] Avoids breaking
[API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces)
changes unless absolutely necessary.
- [x] Testing strategy adequately addresses listed risk(s).
- [x] Change is maintainable (easy to change, telemetry, documentation).
- [x] Release note makes sense to a user of the library.
- [x] Reviewer has explicitly acknowledged and discussed the performance
implications of this PR as reported in the benchmarks PR comment.
- [x] Backport labels are set in a manner that is consistent with the
[release branch maintenance
policy](https://ddtrace.readthedocs.io/en/latest/contributing.html#backporting)
- [x] If this PR touches code that signs or publishes builds or
packages, or handles credentials of any kind, I've requested a review
from `@DataDog/security-design-and-guidance`.
- [x] This PR doesn't touch any of that.
0 commit comments