On Mon, Nov 16, 2015 at 5:15 PM, Michael Selik <mike@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@gmail.com> wrote:_______________________________________________On Mon, Nov 16, 2015 at 3:59 PM, Andrew Barnert <abarnert@yahoo.com> wrote:On Nov 16, 2015, at 10:24, Ryan Gonzalez <rymg19@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@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?--Ryan[ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong.
Python-ideas mailing list
Python-ideas@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.