[Python-ideas] The prohibition overrides the class method

[Ryan Gonzalez]

On Mon, Nov 16, 2015 at 3:59 PM, Andrew Barnert <abarnert at yahoo.com> wrote:

> 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.)
>

Well, it's just as easy to ignore type annotations and call `int(None)`.

(You should definitely patent that hard drive stuff, though! ;)


>
> ...
>
> 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?
>

What about http://programmers.stackexchange.com/a/288974/118754?

-- 
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151116/6e9fe64b/attachment-0001.html>