Skip to content
Snippets Groups Projects
  • Richard van der Hoff's avatar
    4ecf5181
    Include outlier status in `str(event)` for V2/V3 events (#10879) · 4ecf5181
    Richard van der Hoff authored
    I meant to do this before, in #10591, but because I'm stupid I forgot to do it
    for V2 and V3 events.
    
    I've factored the common code out to `EventBase` to save us having two copies
    of it.
    
    This means that for `FrozenEvent` we replace `self.get("event_id", None)` with
    `self.event_id`, which I think is safe. `get()` is an alias for
    `self._dict.get()`, whereas `event_id()` is an `@property` method which looks
    up `self._event_id`, which is populated during construction from the same
    dict. We don't seem to rely on the fallback, because if the `event_id` key is
    absent from the dict then construction of the `EventBase` object will
    fail.
    
    Long story short, the only way this could change behaviour is if
    `event_dict["event_id"]` is changed *after* the `EventBase` object is
    constructed without updating the `_event_id` field, or vice versa - either of
    which would be very problematic anyway and the behavior of `str(event)` is the
    least of our worries.
    Include outlier status in `str(event)` for V2/V3 events (#10879)
    Richard van der Hoff authored
    I meant to do this before, in #10591, but because I'm stupid I forgot to do it
    for V2 and V3 events.
    
    I've factored the common code out to `EventBase` to save us having two copies
    of it.
    
    This means that for `FrozenEvent` we replace `self.get("event_id", None)` with
    `self.event_id`, which I think is safe. `get()` is an alias for
    `self._dict.get()`, whereas `event_id()` is an `@property` method which looks
    up `self._event_id`, which is populated during construction from the same
    dict. We don't seem to rely on the fallback, because if the `event_id` key is
    absent from the dict then construction of the `EventBase` object will
    fail.
    
    Long story short, the only way this could change behaviour is if
    `event_dict["event_id"]` is changed *after* the `EventBase` object is
    constructed without updating the `_event_id` field, or vice versa - either of
    which would be very problematic anyway and the behavior of `str(event)` is the
    least of our worries.
10879.misc 52 B