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) >
_______________________________________________ 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/3MV4ELJBR2SDZ2HAILA3VPAGK5XQ56VW/ Code of Conduct: http://python.org/psf/codeofconduct/
