[Python-ideas] @Override decorator

Michael Selik michael.selik at gmail.com
Tue Jul 19 11:32:40 EDT 2016


On Tue, Jul 19, 2016, 9:51 AM Neil Girdhar <mistersheik at gmail.com> wrote:

> On Tue, Jul 19, 2016 at 10:42 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.
>>
>> 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.
>>
>
> The problem I have with the type annotation behavior that you're proposing
> is that you lose the definition-time assertions that overrides could
> raise.  Even in a small project like mine (20k lines), that would be a big
> asset for me to eliminate a whole class of bugs.
>

Could you explain that further? Are you saying you need an override check
for dynamically created/modified parent classes such that static analysis
would not suffice?

Your second point about people submitting PRs whereby they add decorators
> to everything shouldn't be an argument against new features.  No one is
> forced to use @overrides, and projects can decide for themselves whether
> want to use it.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160719/dfbd5060/attachment-0001.html>


More information about the Python-ideas mailing list