[Python-ideas] The prohibition overrides the class method

[Andrew Barnert]

On Nov 16, 2015, at 10:24, Ryan Gonzalez <rymg19 at gmail.com> wrote:
> 
> You could always put this in the docstring:
> 
> DO NOT OVERRIDE THIS METHOD. IF YOU OVERRIDE THIS METHOD, YOU WILL DIE.
> 
> 
> Short, the-the-point, and evokes fear.

Sure, until the first time someone accidentally violates it and doesn't die. Then you will have trained him to ignore your docstrings, comments, type annotations, and warnings completely. (Of course you could take the OP's code and add some stuff that causes the hard drive casing and spindle to break, firing the platter at the developer's skull like one of those discs from the Dolph Lundgren movie I Come in Peace, but that would break compatibility with computers that only have SSDs, and I don't think that's feasible in 2015.)
> 
> ...
> 
> Seriously, though, I personally think this might go well with the whole PEP 484 type-annotation thing. I mean, if there are already generics and abstract methods. If we're going for static typing, adding final would fit well. Something like:
> 
> @finalmethod
> def whatever(self): ...
> 
> The type checker (in this case, Mypy) would check it, but there would be no runtime effect.

Yes, that makes sense. If the feature isn't supposed to have any runtime effect, and is modeled after something that's definitely compile-time-centric in C++ and friends, signaling that by importing it from typing seems to be a pretty clear way to get that across.

Although I still don't know why we need it. See below:

>> On November 16, 2015 12:15:55 PM CST, "Иван Спиненко" <spinenkoia at gmail.com> wrote:
>> Thank you for the constructive responses, perhaps, I agree with you that this is not in the spirit of Python.
>> As for the real example of the use, sometimes there to make the implementation of the method in the base class, but that none of the rest of the development team could not accidentally or unknowingly override this method (perhaps due to the need to be unsuccessful architecture).

If it's just part of the implementation of the base class, just double-underscore it so that it can't be accidentally overridden (or called).

It's only when something is also part of the interface that this is a problem. And it's kind of strange to have something be part of the interface of a type, but not be refinable by subtypes. When would you want that? (And as for accidental overriding, if a class claims doesn't even know what the interface of some supertype is, it probably shouldn't be inheriting—either it should be a mixin for someone who does know the supertype to compose, or it should be encapsulating rather than inheriting.)

Do you have a concrete example of some code where you wanted finalmethod, and would use it to prevent the rest of your team from overriding it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151116/3c3e7fdb/attachment-0001.html>