[Python-ideas] @Override decorator
mistersheik at gmail.com
Wed Jul 20 00:01:02 EDT 2016
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.
On Tue, Jul 19, 2016 at 11:32 AM Michael Selik <michael.selik at gmail.com>
> 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...
More information about the Python-ideas