On 26 November 2016 at 07:16, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 26 November 2016 at 13:26, Guido van Rossum <guido@python.org> wrote:
I think one reason why such proposals are unwelcome to experienced users may be that when done right this is totally legitimate, and the requirement to use an @override decorator is just making code more verbose with very little benefit.
It's also the case that if we're going to provide decorators to help with class definitions, there are more valuable things that we can do beyond merely warning about accidental method and attribute overrides.
This comment made me think about another potential issue with the @override proposal. If overriding a method without using the decorator were to produce a warning, how would that interact with custom class decorators or metaclasses that inject methods into a class? Would they have to take special care to detect and mark overrides? While it's true that if a custom metaclass injects an unintended override, that's just as much a problem as if the user explicitly writes one, the problem arises for the end user of such a custom metaclass, who will get an obscure warning about internals that they probably don't know how to fix. Nothing insurmountable, sure, but it does act as a reminder that a change like this could have pretty wide reaching implications... Paul