Hm, having a public API to do that would be nice. It seems there are two implementations, one in Python, one in C. Maybe it's time you opened a bpo issue and started working on a PR? This just seems too reasonable to keep bugging python-ideas...
On Thu, Oct 1, 2020 at 7:55 AM Ben Avrahami <avrahami....@gmail.com> wrote: > In theory, all that's necessary is to just run `_py_abc`'s abstract method > population again (`ABCMeta.__new__`, with slight adjustments): > > def update_abstractmethods(cls): > if not isinstance(cls, ABCMeta): > return cls > abstracts = set() > # include only abstract methods that are not implemented > for name in cls.__abstractmethods__: > value = getattr(cls, name, None) > if getattr(value, "__isabstractmethod__", False): > abstracts.add(name) > # check for new abstract methods > # note that for most cases this loop is useless and can be > scrapped for a minimal solution > for name, value in cls.__dict__.items(): > if name not in abstracts \ > and getattr(value, "__isabstractmethod__", False): > abstracts.add(name) > cls.__abstractmethods__ = frozenset(abstracts) > return cls > > My preferred API will be to just add this function into `abc`, but the > minimal solution is to just airdrop this behaviour into `dataclass` (and > possibly `total_ordering`), and let 3rd parties implement this logic > themselves. > > On Thu, Oct 1, 2020 at 5:08 PM Guido van Rossum <gu...@python.org> wrote: > >> That might work (though not for older Python versions). What kind of API >> were you thinking of for adding and deleting abstract methods? >> >> On Thu, Oct 1, 2020 at 01:07 Ben Avrahami <avrahami....@gmail.com> wrote: >> >>> >>> >>> I suppose it's better than nothing, since right now libraries are >>> (rightfully) afraid to modify it or rely on its behaviour. Although I >>> expect this will lead to a lot of repeated code, that looks a lot like the >>> `__abstractmethods__` population in `_py_abc`. I think it's preferable to >>> ease abstract method re-population for 3rd (and 1st) party libraries, but >>> the dev team probably knows better. If this is an accepted solution, I'd be >>> happy to write a BPO and PR. >>> >>> On Wed, Sep 30, 2020 at 5:30 PM Guido van Rossum <gu...@python.org> >>> wrote: >>> >>>> 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) >>>> >>>> >>>> >>> >>> -- >> --Guido (mobile) >> > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ 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/K4725I42N4H2SK7LKOBMYQJQCQWE37UW/ Code of Conduct: http://python.org/psf/codeofconduct/
