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