[Python-ideas] The prohibition overrides the class method

[Michael Selik]

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

Btw, why does my iPad not have a back tick on the keyboard? My Android can
do it...

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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151116/28a88e48/attachment.html>