[Python-ideas] Re: Trouble with "decorator mixins" and ABCs

Would it help if ‘__abstractmethods__’ was documented, overruling whatever the PEP says? On Wed, Sep 30, 2020 at 00:01 Ben Avrahami 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 wrote:

...

On 9/29/2020 10:49 AM, Ben Avrahami

wrote:

On Tue, Sep 29, 2020 at 4:53

PM Bar Harel 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)