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