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

[Scott David Daniels]

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 at Acm.Org