[Python-ideas] The prohibition overrides the class method

[Ryan Gonzalez]

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/b4a34b34/attachment.html>