[Python-ideas] Decorator to avoid a mistake

[Nick Coghlan]

On 26 November 2016 at 21:15, Paul Moore <p.f.moore at gmail.com> wrote:
> On 26 November 2016 at 07:16, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On 26 November 2016 at 13:26, Guido van Rossum <guido at 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?

It would potentially be even more annoying than that - if we did
something like this without being sufficiently careful about it, you'd
need to use the decorator any time you overwrote a special method
that's actually implemented on "object". Ditto for method overrides
when inheriting from an abstract base class, or any other base class
that defines an API where the base class method implementation raises
NotImplementedError.

By contrast, if it's opt-in via a class decorator, then folks that
want additional definition time assistance from the interpreter can
request that explicitly, while existing code remains unaffected.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia