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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4