PEP 698: A typing.override decorator

Hi All,

We’d like to put PEP 698 forward for discussion.

The proposal is for a new decorator @typing.override that marks a method as overriding a method in some superclass. Having this decorator - inspired by similar constructs in Java, C++, Typescript, Kotlin, Scala, Swift, and C# - will enable static type checkers to detect potential bugs where a base class method is renamed but child classes were not modified.

Previous discussion has been on typing-sig, in particular here is the original discussion.

6 Likes

Really looking forward to this!

Just curious, but why does it list this as a disadvantage?

“Adding or removing base class methods that impact overrides will require updating subclass code.”

Isn’t being forced to update subclass code one of the benefits of the decorator?

Also, I proposed something similar in the ipromise library. I allowed for the possibility of indicating from which base class the overridden base method comes from. In some situations, that can help readers of code know where to look for the method, and it’s a bit stricter (if one base class removes, say, the __call__ method, but another one adds it–and you meant to override the one from the first base class). If you’re so inclined, feel free to include this under rejected/considered ideas.

Good point regarding the odd choice of words!

I think the disadvantages wording should be tweaked to emphasize a verbosity tradeoff - what we had intended to point out was that (as with static types in general) this introduces another tradeoff where code becomes more verbose in order to gain some safety.


As for specifying the parent class, my initial impression is that while it could be useful (especially making the overridden class explicit to help with code navigation), it probably isn’t worth including in PEP 698 for three reasons:

  • if in a single commit you move a method from one base to another, you as the author are likely aware of what you did, so the safety benefits are relatively small
  • I’m guessing there wouldn’t be too much use of this feature. Since it’s relatively easy to implement this capability using runtime logic in a library, that makes me thing we don’t need to bake it into typing.py all of the type checkers.

But I’d like to get opinions from others as well, I just posted a link to this discussion in typing-sig so we can see if there is a range of opinions.

If the consensus is not to include that functionality, we could add it under the considered ideas.

Yes, I completely agree with your reasons, and I figured you would probably have thought of this. I was just wondering if you should mention these reasons in the PEP under “rejected alternatives”? In a few years, this extension may be posted on python-ideas, and then it might be useful for that poster to see your rejection reasoning.

That said, @typing.override could support both usage with and without the base class. But I agree that use of the base class would happen extremely rarely (only in a very complicated inheritance hierarchy). But anyway, the use of a base class could always be added later if someone makes a compelling case for it.

If the consensus is not to include that functionality, we could add it under the considered ideas.

Fair enough :smile:

The first versions of ”runtime” overriding decorator actually contained the class name inheritance - In Python, how do I indicate I'm overriding a method? - Stack Overflow but that really did not bring any benefits. From my point of view it only made it harder to use. Big jump was to discover a way to leave that out.
Nobody has asked for explicitly naming the class in overrides lib in the past 10 years, so I would assume it is not needed.

1 Like

Thanks to both Niel for the suggestion and Mikko for sharing past experience with this approach.

I’ve put up a PR to include this idea in the “Rejected Alternatives” selection: