Hi all, Quite coincidentally I recently asked about this on stackoverflow ( https://stackoverflow.com/questions/72316756/python-mark-method-as-implement...). The purpose was twofold, first and foremost tell my fellow programmer that I intend to override/implement a base class/protocol method. Scond, allow for tools to detect that a parent method would be renamed and the child method would not actually override anything. Regarding the potential naming confusion: I am convinced this is a temporary thing. Yes, there will be mistakes, but no more than mistaking ValueError and KeyError, or iterator and iterable. This is standard computer science terminology, so there are plenty of reasons to follow it. Python users are smart enough to pick up the difference ;). Kind regards Kristoffel On Mon, May 23, 2022 at 10:24 PM Teddy Sudol via Typing-sig < typing-sig@python.org> wrote:
We’ve seen runtime bug reports usually caused by an engineer renaming a parent class method and forgetting to rename that method in all child classes.
This is an interesting case -- the new pytype feature Martin mentioned wouldn't catch this. If it wasn't for all the other languages, I'd lean towards this being an IDE feature that's powered by the type checkers.
-- Teddy
On Mon, May 23, 2022 at 12:49 PM Shannon Zhu via Typing-sig < typing-sig@python.org> wrote:
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.ht... ). 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 _______________________________________________ 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: tsudol@google.com
_______________________________________________ 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: kristoffel.pirard@gmail.com