[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