[Python-ideas] method decorators @final and @override in Python 2.4
Péter Szabó
ptspts at gmail.com
Sun Mar 29 20:37:38 CEST 2009
> class MostlyAbstract(object):
> @override
> def __hash__(self, other):
> pass
> @override
> def __lt__(self, other):
> pass
> @override
> def __eq__(self, other):
> pass
> def __le__(self, other):
> return self.__lt__(other) or self.__eq__(other)
> def __gt__(self, other):
> return other.__lt__(self)
> def __ge__(self, other):
> return self.__gt__(other) or self.__eq__(other)
>
> and I decide then comparison should works a bit differently:
>
> class MostAbstract(MostlyAbstract):
> def __gt__(self, other):
> return not self.__le__(self)
>
>
> This choice of mine won't work, even when I'm trying to just do a
> slight change to your abstraction.
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.)
> def __init__(self, name, supers, methods):
> type.__init__(self, name, supers, methods)
> if hasattr(self, '__initclass__'):
> self.__initclass__()
Thanks for the idea, this sounds generic enough for various uses, and
it gives power to the author of the subclass. I'll see if my
decorators can be implemented using __initclass__.
More information about the Python-ideas
mailing list