Would it help if ‘__abstractmethods__’ was documented, overruling whatever the PEP says?
On Wed, Sep 30, 2020 at 00:01 Ben Avrahami <avrahami....@gmail.com> wrote: > 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/ > > -- --Guido (mobile)
_______________________________________________ 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/ORMDYKVIJOAFMOT3HESFLMEKJLKTQ4MQ/ Code of Conduct: http://python.org/psf/codeofconduct/