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? 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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
