[Python-ideas] @Override decorator

[Neil Girdhar]

On Tue, Jul 19, 2016 at 10:42 AM Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 19 July 2016 at 16:44, Neil Girdhar <mistersheik at gmail.com> wrote:
> > Why can't @overrides be processed at definition time?
>
> I didn't say it can't, I said I think it shouldn't be, and it
> shouldn't be for the same reason we don't process type annotations at
> runtime: this proposal falls into the realm of gradual typing, and
> gradual typing is an *optional* behaviour for use on projects that are
> sufficiently large with high enough personnel churn to see the
> benefits that outweigh the cost in boilerplate.
>
> With PEP 484 and typing, we've already established the precedent that
> people shouldn't go rushing off to their favourite projects and submit
> low value PRs that just add annotations for the sake of adding
> annotations. The proposed decorator here is a different kind of
> semantic annotation, but it's still one that should only be added to a
> project if the existing contributors to that project think it will
> help them maintain the code.
>

The problem I have with the type annotation behavior that you're proposing
is that you lose the definition-time assertions that overrides could
raise.  Even in a small project like mine (20k lines), that would be a big
asset for me to eliminate a whole class of bugs.

Your second point about people submitting PRs whereby they add decorators
to everything shouldn't be an argument against new features.  No one is
forced to use @overrides, and projects can decide for themselves whether
want to use it.

>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160719/578a9eab/attachment.html>