
Right, just to clarify – the proposal is not to start erroring on incompatible overrides (which I think all type checkers do already), but to support a way to mark a method as “this method must override something in the parent – it is a type error if that is not true”. Some questions: * Naming confusions with “overload” does seem to be an issue. I’m not sure if there is a good alternative name besides “override”, though. Thoughts? * Should we support marking a class as “enforcing explicit overrides”, which means any subclasses must use the “override” decorator to override any methods in the parent? I agree with Eric that we shouldn’t push this as a core expectation, but curious if also having a class level opt-in allows for more confidence when refactoring than only a per-method opt-in. From: Eric Traut <eric@traut.com> Date: Friday, May 20, 2022 at 7:38 PM To: typing-sig@python.org <typing-sig@python.org> Subject: [Typing-sig] Re: typing.override decorator I think this is a useful construct, and I like the proposal. TypeScript has an `overload` keyword for this purpose (see https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-3.html#override-and-the---noimplicitoverride-flag<https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-3.html#override-and-the---noimplicitoverride-flag> ). A decorator is a natural way to add this functionality in Python. I agree that this should be opt-in at the method level and should not be pushed as a core expectation for all well-annotated code. -- Eric Traut Contributor to Pyright & Pylance Microsoft _______________________________________________ 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/<https://mail.python.org/mailman3/lists/typing-sig.python.org/> Member address: szhu@fb.com