I encountered this problem when I needed to implement a class that defined all 4 of the comparison operators, once with `dataclass` (for one implementation) and once with `total_order` (for another).Also, 3rd party libs are expected to fall down this rabbit hole, and unless they're expected to modify `__abstractmethods__` and perform abstract logic on their own- I don't see why the standard library should keep such computations unavailable.
On Tue, Sep 29, 2020 at 6:41 PM Eric V. Smith <e...@trueblade.com> wrote: > On 9/29/2020 10:49 AM, Ben Avrahami wrote: > > On Tue, Sep 29, 2020 at 4:53 PM Bar Harel <bzvi7...@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 > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/EQQVNE4IVG5ZLWZHY3HCIATUY32PHWJG/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ASPJKUZ46MAD5FT6HOLIFSQDFZR7IFGY/ Code of Conduct: http://python.org/psf/codeofconduct/
