On Tue, Jul 19, 2016, 12:08 PM Wes Turner
On Jul 19, 2016 10:43 AM, "Nick Coghlan"
wrote: On 19 July 2016 at 16:44, Neil Girdhar
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.