[Python-ideas] @Override decorator

[Michael Selik]

On Tue, Jul 19, 2016, 12:08 PM Wes Turner <wes.turner at gmail.com> wrote:

> 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
>
This is an argument for adding this feature to the typing module as opposed
to a decorator, correct?

Changing the base dynamically would not trigger another call to @overrides,
even with some fancy metaclassing. The check wouldn't occur until
instantiation or calling the method.

Going for instantiation-time checks could get awkward via metaclass. To
avoid conflicts I guess OverrideMeta would be an extension of ABCMeta. If
just using __new__ it's too easy to accidentally bypass.

Call-time checks would add overhead to every method call.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160719/c815c6ee/attachment.html>