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 ). 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/
Member address: szhu@fb.com