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?
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. 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. Further, the entire warp drive test is not started if we stupidly spell the second "test_result" (as it was on the Enterprise tests). --Scott David Daniels Scott.Daniels@Acm.Org