Message377851
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. |
|
Date |
User |
Action |
Args |
2020-10-03 04:55:04 | gvanrossum | set | recipients:
+ gvanrossum, rhettinger, eric.smith, python-dev, avrahami.ben |
2020-10-03 04:55:04 | gvanrossum | set | messageid: <1601700904.2.0.475360456827.issue41905@roundup.psfhosted.org> |
2020-10-03 04:55:04 | gvanrossum | link | issue41905 messages |
2020-10-03 04:55:04 | gvanrossum | create | |
|