On Mon, 30 Mar 2009 06:26:16 am Scott David Daniels wrote:
Péter Szabó wrote: ...
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. What I understand about your mails is that your definition is: if there is @override on A.F, then any subclass of A must override A.F. Do I get the situation of the different understanding right? If so, do you find anything in my definition which prevents code reuse? (I don't.)
Nor do I. I completely misunderstood what you meant by override, and I agree that what you are specifying there _is_ a help to those writing code (I'd document it as a way of marking an intentional override).
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. If @override is just a way of catching spelling mistakes, perhaps it would be better in pylint or pychecker. What have I missed? -- Steven D'Aprano