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__.