On 26 November 2016 at 21:15, Paul Moore <p.f.mo...@gmail.com> wrote: > On 26 November 2016 at 07:16, Nick Coghlan <ncogh...@gmail.com> wrote: >> On 26 November 2016 at 13:26, Guido van Rossum <gu...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
