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

[Steven D'Aprano]

On Mon, 30 Mar 2009 09:03:03 am Scott David Daniels wrote:
> Steven D'Aprano wrote:
> > ... Perhaps I just haven't worked on enough 20,000 line projects,
> > but I don't get the point of @override. It doesn't prevent somebody
> > from writing (deliberately or accidentally) B.F in the absence of
> > A.F, since the coder can simply leave off the @override.
>
> ? B.F vs. A.F?  Could you expand this a trifle?

Classes B and A, method F.


In case it is still unclear, I'm referencing Péter Szabó's post, which 
we both quoted:

> > I think we have a different understanding what @override means. I
> > define @override like this: ``class B(A): @override def F(self):
> > pass'' is OK only if A.F is defined, i.e. there is a method F to
> > override.

The intention is that this will fail:

class A: pass

class B(A):
    @override
    def F(self): pass

but this will be okay:

class A: 
    def F(self): pass

class B(A):
    @override
    def F(self): pass


But if I leave out the @override then I can define B.F regardless of 
whether or not A.F exists, so it doesn't prevent the creation of B.F.



> > If @override is just a way of catching spelling mistakes, perhaps
> > it would be better in pylint or pychecker. What have I missed?
>
> If, for example, you have a huge testing framework, and some
> developers are given the task of developing elements from the
> framework by (say) overriding the test_sources and test_outcome
> methods, They can be handed an example module with @override
> demonstrating where to make the changes.

"# OVERRIDE" or "# TODO" will do that just as well.

>      class TestMondoDrive(DriveTestBase):
>
>          @override
>          def test_sources(self):
>              return os.listdir('/standard/mondo/tests')
>
>          @override
>          def test_outcome(self, testname, outcome):
>              if outcome != 'success':
>                  self.failures('At %s %s failed: %s' % (
>                      time.strftime('%Y.%m.%d %H:%M:%S'),
>                      test_name, outcome))
>              else:
>                  assert False, "I've no idea how to deal with
> success"
>
> The resulting tests will be a bit easier to read, because you can
> easily distinguish between support methods and framework methods.

Maybe so, but comments and/or naming conventions do that too.


> Further, the entire warp drive test is not started if we stupidly
> spell the second "test_result" (as it was on the Enterprise tests).

That's a reasonable benefit, but it still sounds to me like something 
that should go in pylint.

I don't really have any objection to this, and Guido has already said it 
should go into a third party module first. Thank you for explaining the 
use-case.




-- 
Steven D'Aprano