[Python-ideas] @Override decorator

Wes Turner wes.turner at gmail.com
Tue Jul 19 13:08:13 EDT 2016


On Jul 19, 2016 10:43 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.

Is there enough information, in all cases, to do the check at definition
time?

- Obviously this wouldnt work for AOP-style dynamic mixins which are/could
be modified by changing {__bases__, __class__, ...?} at runtime (certainly
an infrequent use case and a different style of composition than
@override-relevant inheritance)
- __new__

>
> 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.

What reasons are there for @override to be in stdlib?:
- no import required (though it would still be necessary for backwards
compatibility)
- cross-cutting concerns
  - definition-time type verificayions
  - runtime type verifications

aside: Spring Python may be of interest to people more familiar with Java

>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160719/a2440c19/attachment.html>


More information about the Python-ideas mailing list