[Python-ideas] The prohibition overrides the class method

[Michael Selik]

Ryan, are you saying that

def helper(self):
pass

__helper = helper

Would not be sufficient protection against clumsy subclassing?

On Mon, Nov 16, 2015 at 6:22 PM Ryan Gonzalez <rymg19 at gmail.com> wrote:

> On Mon, Nov 16, 2015 at 5:15 PM, Michael Selik <mike at selik.org> wrote:
>
>> For that envelopes example on StackExchange, I'd probably use name
>> mangling to reduce chances of subclassing mistakes and have prepare() call
>> stuff(), seal(), stamp() in the correct order or whatever those were. I'm
>> not sold in the need for "final".
>>
>>
> Maybe the subclasses should be able to access the functions. They just
> shouldn't override it.
>
>
>> Btw, why does my iPad not have a back tick on the keyboard? My Android
>> can do it...
>>
>>
> Android > iPad.
>
> *ducks from incoming bullets*
>
>
>> On Mon, Nov 16, 2015 at 5:53 PM Ryan Gonzalez <rymg19 at gmail.com> wrote:
>>
>>> 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/
>>>
>>> _______________________________________________
>>> 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/
>>
>>
>
>
> --
> 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/aa874815/attachment-0001.html>