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.ben@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 <guido@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.ben@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 <eric@trueblade.com> wrote:
On 9/29/2020 10:49 AM, Ben Avrahami
wrote:
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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/EQQVNE...
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@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/ASPJKU...
Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido (mobile)
--
--Guido (mobile)