Home Original page

[Python-Dev] deprecation of abstractstaticmethod and abstractclassmethod

Nick Coghlan ncoghlan at gmail.com
Tue May 21 10:30:46 EDT 2019 
On Thu, 16 May 2019 at 06:03, Steve Dower <steve.dower at python.org> wrote:
>
> On 15May2019 1248, Nathaniel Smith wrote:
> > I don't care about the deprecation either way. But can we fix the
> > individual decorators so both orders work? Even if it requires a special
> > case in the code, it seems worthwhile to remove a subtle user-visible
> > footgun.
>
> The classmethod and staticmethod objects already have a getter for
> __isabstractmethod__ that forwards to the underlying object, so they
> should just need a setter as well, right?

I believe the problem with the reverse direction relates to
abstractmethod correctly forwarding __get__ to the underlying
descriptor (or not), rather than having anything to do with the
`__isabstractmethod__` property forwarding.

However, I *don't* recall if we ever actually tried to make the
reverse direction work - it may be that there's a relatively shallow
enhancement that would let `@abstractmethod` wrap arbitrary decorators
correctly.

> I also have no strong opinion about deprecation. But fixing this seems
> pretty straightforward and may be a good task for someone's first C
> contribution?

If the reverse order can be made to work, that would be good, but if
that proves intractable, Ethan's suggestion of reversing the
documented deprecation makes sense.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
More information about the Python-Dev mailing list