Steven D'Aprano wrote:
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. ... The intention is that this will fail: ... but this will be okay: ... 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. Thanks for the expansion. The check is not so much to prevent creating B.F, as it is asserting we are plugging into a framework here.
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.
Yes, after all we did lose all of sector 4.66.73 on that unfortunate accident :-). I agree that it does feel a bit pylint-ish, but I have work on large unwieldy frameworks where large machines get powered on by the framework as part of running a test, and it is nice to see the whole test not even start in such circumstances. This is why I wrote that (easily ponied in) possible addition to type named "__initclass__", it seemed a more-useful technique that could be be used by the OP to implement his desires, while providing a simple place to put class initialization code that allows people to get a bit fancier with their classes without having to do the metaclass dance themselves. I'll try to putting up an ActiveState recipe for this in the coming week. --Scott David Daniels Scott.Daniels@Acm.Org