[Python-ideas] @Override decorator

[Neil Girdhar]

On Tue, Jul 19, 2016 at 1:19 AM Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 19 July 2016 at 14:04, Guido van Rossum <guido at python.org> wrote:
> > The same argument would apply against abstractmethod... I have definitely
> > wondered when looking over some code whether it was defining or
> overriding a
> > method. But requiring people to always decorate overrides seems hard,
> unless
> > we made it a property that can be enforced by a metaclass, maybe?
>
> This is trickier in Python than it is in Java, since we support
> multiple inheritance, and we don't require that subclasses be drop-in
> replacements for their parent class.
>
> The key difference I see between @abstractmethod and this proposal is
> that @abstractmethod is a service that base class authors provide to
> subclass authors to say "Hey, when subclassing this, you *need* to
> override these, or your subclass won't work properly". In effect, it's
> an implicit test case for all future subclass definitions.
>
> By contrast, this proposal would go in the other direction: it would
> be an assertion by the author of a *subclass* that that particular
> method isn't new, it's inherited from a parent class, and they're
> replacing the existing implementation with a new one. It would only
> add new information for readers in cases where the method wasn't
> already calling super() (since the latter already implies you expect
> there to be at least one further implementation along the MRO to
> call).
>
> In my view, that puts it more in the category of type annotations and
> the "missing attribute" detection in tools like pylint than it does
> abstractmethod: rather than checking it at runtime, you'd want static
> checkers like mypy to flag it as a structural error if a method
> declared as replacing a base class method wasn't actually doing so.
>

Why can't @overrides be processed at definition time?   It could check one
of two cases: either you're replacing an abstractmethod, in which case the
parameter lists should be the same; or else, you're overriding a base class
method in which case, you should probably call super.  Finally, it could
prepend the __doc__ attribute from the parent class method if there is one
to the doc attribute on this method if there is one.

>
> So a "typing.override" to complement "typing.overload" would make
> sense to me, but a checked-at-runtime decorator wouldn't (doing it
> that way would also let you put the override annotation in stub files
> instead of directly in the code).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/V6sUaArzGC0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160719/532e6a35/attachment-0001.html>