[Python-ideas] @Override decorator

[Neil Girdhar]

You're right (and so is Nick): the static analysis would suffice.  I guess
you don't get the automatic docstring copying.  My personal feeling is that
it is also nice to have (even if I don't use it) support for dynamically
created/modified parent classes.

Best,

Neil

On Tue, Jul 19, 2016 at 11:32 AM Michael Selik <michael.selik at gmail.com>
wrote:

>
>
> 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/20160720/2297a72b/attachment-0001.html>