On Tue, Sep 29, 2020 at 4:53 PM Bar Harel <bzvi7919@gmail.com> wrote:

I'd like to bring another insight to the table: According to the pep, "Dynamically adding abstract methods to a class, or attempting to modify the abstraction status of a method or class once it is created, are not supported."

The notice exists both in the pep and at the abc module's docs, and is exactly what this idea is all about.

My question is why? Was there an objection for implementing such a thing, or was it complex enough to postpone for the time being?

I think this is fine. The "abstract-ness" of a class is not supposed to change throughout its lifetime. The problem arises when decorators change the class before it's ever used, as that should still be considered its "initialization" as far as the user is concerned, so its "abstract-ness" should change accordingly.

I agree with Guido in that the cleanest solution is to change the decorators. Perhaps a module function to recalculate a class's __abstractmethods __, that mixin decorators can call prior to returning the class. I can't really think of standard library class decorators that would use this global function other than `dataclass` and `total_ordering`, but in this way, 3rd party decorators can easily support implementing abstract functions.

The one downside to this solution is that it can easily be abused by calling it in the middle of a class's lifetime.

I think I'd like to see dataclasses handle this directly, so as to keep it easy to use. But I can be argued with: it's not like a beginner would stumble over this issue.

Eric