[issue41905] add update_abstractmethods function to update an ABC's abstract methods
Guido van Rossum
report at bugs.python.org
Sat Oct 3 00:55:04 EDT 2020
Guido van Rossum <guido at 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 <report at bugs.python.org>
<https://bugs.python.org/issue41905>
_______________________________________
More information about the Python-bugs-list
mailing list