<br><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 19, 2016, 12:08 PM Wes Turner <<a href="mailto:wes.turner@gmail.com">wes.turner@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr"></p>
<p dir="ltr">On Jul 19, 2016 10:43 AM, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
><br>
> On 19 July 2016 at 16:44, Neil Girdhar <<a href="mailto:mistersheik@gmail.com" target="_blank">mistersheik@gmail.com</a>> wrote:<br>
> > Why can't @overrides be processed at definition time?<br>
><br>
> I didn't say it can't, I said I think it shouldn't be, and it<br>
> shouldn't be for the same reason we don't process type annotations at<br>
> runtime: this proposal falls into the realm of gradual typing, and<br>
> gradual typing is an *optional* behaviour for use on projects that are<br>
> sufficiently large with high enough personnel churn to see the<br>
> benefits that outweigh the cost in boilerplate.</p>
<p dir="ltr">Is there enough information, in all cases, to do the check at definition time?</p>
<p dir="ltr">- Obviously this wouldnt work for AOP-style dynamic mixins which are/could be modified by changing {__bases__, __class__, ...?} at runtime</p></blockquote></div><div>This is an argument for adding this feature to the typing module as opposed to a decorator, correct?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Call-time checks would add overhead to every method call.</div><div class="gmail_quote"></div>