A few weeks back we merged PEP 698 for `typing.override` as a draft PEP, with no significant changes since the typing-sig discussion in [1] One of the things we decided for the initial proposal was to avoid any runtime behavior; we considered setting `__override__` but decided not to because (a) it is hard to get the ordering of decorators right for runtime behavior, it depends on which decorators are descriptor- versus wrapper-function-based (b) some objects have fixed slots and therefore cannot have `__override__` set at all, there's no way to produce runtime behavior in these cases I think we should reconsider for two reasons: (a) The author of the overrides library got back to us and specifically requested this [2], because he believes there's potential for libraries to make runtime use of @override, for example automatically applying docstrings from parent classes to child classes which could be useful for notebook users (b) We do indeed set a `__final__` attribute in the @final decorator [3], and after some more thought I think consistency is important My current opinion is that we should make a best-effort attempt to set the attribute (as we do in `@typing.final`) and document edge cases that can impact runtime behavior, while ignoring those edge cases in static checkers. Are there any objections before I start working on these changes? ------------------- [1] Previous thread about typing.override proposal: https://mail.python.org/archives/list/typing-sig@python.org/message/7JDW2PKG... [2] Discussion in peps repo regarding `__override__` https://github.com/python/peps/pull/2830 [3] @typing.final logic today: https://github.com/python/cpython/blob/main/Lib/typing.py#L2630-L2636