This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients avrahami.ben, eric.smith, gvanrossum, python-dev, rhettinger
Date 2020-10-03.04:55:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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

class MyClass(SomeAbstractBaseClass):
    def __lt__(self, other):

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

class MyAbstractClass(abc.ABC):
    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 and 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:04gvanrossumsetrecipients: + gvanrossum, rhettinger, eric.smith, python-dev, avrahami.ben
2020-10-03 04:55:04gvanrossumsetmessageid: <>
2020-10-03 04:55:04gvanrossumlinkissue41905 messages
2020-10-03 04:55:04gvanrossumcreate