Guido van Rossum <gu...@python.org> added the comment:
I still like to have a helper that recalculates the abstractness status of a
class after adding some new methods (or deleting some).
I would prefer the isinstance(cls, ABCMeta) check to be inside that helper, so
that you could call it unconditionally after adding/deleting methods:
abc.update_abstractmethods(cls). (It doesn't really need a comment saying
"Update abstract methods" either. :-)
In fact, its signature makes the helper feasible as a class decorator itself,
so that users who are using a mixin class decorator that doesn't update
abstractness can add it conveniently themselvs. E.g. suppose @total_ordering
didn't make this call itself, then the user could write
@abc.update_abstractmethods
@functools.total_ordering
class MyClass(SomeAbstractBaseClass):
def __lt__(self, other):
whatever
But I think it would be nice if @total_ordering and @dataclass did include this
call.
However, I don't see why @total_ordering needs to be changed to also override
abstract methods *defined in the decorated class*. If I write
@functools.total_ordering
class MyAbstractClass(abc.ABC):
@abc.abstractmethod
def __lt__(self, other):
return NotImplemented
it's totally clear to me what @total_ordering should do -- it should define
__le__, __gt__ and __ge__ in terms of __lt__, and leave __lt__ alone, for some
subclass to implement.
With these two amendments, the changes to dataclasses.py and functools.py are
limited to two lines (adding the call to abc.update_abstractmethod(cls)), plus
an import change.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue41905>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
