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

On Jul 19, 2016 10:43 AM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
>
> On 19 July 2016 at 16:44, Neil Girdhar <mistersheik@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.