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/7JDW2PKGF6YTERUJGWM3BRP3GDHRFP4O/

[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
_______________________________________________
Typing-sig mailing list -- typing-sig@python.org
To unsubscribe send an email to typing-sig-leave@python.org
https://mail.python.org/mailman3/lists/typing-sig.python.org/
Member address: guido@python.org