Hi, Thanks for pointing out that a @final decorator in the superclass can be an obstacle for code reuse if we assume that the author of the subclass has no (or has only limited) control over the code of the superclass. I'll come up with features with which the subclass can bypass some or all decorators imposed in the superclass. (One easy way to do this right now is saying ``__metaclass__ = type'' in the subclass.) I agree that the programmer of the subclass is the one who knows best whether a method needs overriding. We have to give the programmer the power to enforce his will. But I think the errors coming from the decorators are very useful for notifying the programmer of the subclass that he is trying to something unexpected -- then he should make his decision to reconsider or enforce (e.g. @override_final as suggested by Nick Coghlan). By raising an error we inform the programmer that there is a decision he has to make. I think using a metaclass for implementing the checks based on the decorator is more appropriate than just overriding __new__ -- because we want to hook class creation (for which a metaclass is the adequate choice), not instance creation (for which overriding __new__ is the right choice). I definitely don't want any check at instance creation time, not even once. If I managed to create the class, it should be possible to create instances from it without decorator checks. By the way, as far as I can imaginge, using __new__ instead of the metaclass wouldn't make the implementations I can come up with simpler or shorter. A nice English docstring saying ``please don't override this method'' wouldn't make me happy. In my use case a few programmers including me are co-developing a fairly complex system in Python. There are tons of classes, tons of methods, each of them with docstrings. When I add some methods, I sometimes assume @final or @override, and I'm sure the system would break or function incorrectly if somebody added a subclass or changed a superclass ignoring my assumptions. Let's suppose this happens, but we don't notice it early enough; it becomes obvious only days or weeks later that the system cannot work this way, and the original reason of the problem was that somebody ignored a @final or @override assumption, because he didn't pay close attention to the thousands of docstrings. So we wast hours or days fixing the system. How can we avoid this problem in the future? Option A. Rely on writing and reading docstrings, everybody always correctly. Option B. Get an exception if a @final or @override assumption is violated. Option B is acceptable for me, Option A is not, because with option A there is no guarantee that the overlooking won't happen again. With Option B the programmer gets notified early, and he can reconsider his code or refactor my code early, must faster than fixing it weeks later. Best regards, Péter