[Python-ideas] method decorators @final and @override in Python 2.4

[Péter Szabó]

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