Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

decorators: add __self__ #70

Merged
merged 3 commits into from
Dec 17, 2020
Merged

Conversation

JelleZijlstra
Copy link
Collaborator

@@ -48,6 +48,8 @@ class DecoratorBinder(object):
def __init__(self, decorator, instance=None):
self.decorator = decorator
self.instance = instance
if instance is not None:
self.__self__ = instance
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Setting __self__ only for bound methods is consistent with how normal Python methods behave, since unbound methods don't have __self__. On the other hand, it's a bit weird for an attribute to only be present on the same type of object some of the time, so maybe we should just set __self__ to None in the unbound case.

What do you think @besfahbod?

Copy link
Contributor

@besfahbod besfahbod Dec 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Yeah, I agree. Here's my reasoning:

  • It does makes sense for PY to do so in the basic lang-item object types, keeping the API surface as small as possible.
  • In this library, however, we're dealing with higher-level objects, specially ones that can work on multiple lang-item types. If we did have generics support over those types, we probably could be more specific. But since we don't, it's good to keep the API consistent regardless of the type of lang-item.

So, should we just drop the condition check, then?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, done

Copy link
Contributor

@besfahbod besfahbod left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome! 🎉

@JelleZijlstra JelleZijlstra merged commit 2d143c0 into quora:master Dec 17, 2020
@JelleZijlstra JelleZijlstra deleted the dunderself branch December 17, 2020 19:39
@JelleZijlstra
Copy link
Collaborator Author

This caused some problems internally because some code assumes that anything with __self__ also has __func__. We could add __func__ too (replacing .decorator), but I should do some more testing.

@JelleZijlstra
Copy link
Collaborator Author

@besfahbod do you mind if I revert this to avoid trouble with other libraries? Deploying the change seems risky now and it's easy for tools that want to work with decorators to use .instance instead.

JelleZijlstra added a commit that referenced this pull request Jan 4, 2021
@besfahbod
Copy link
Contributor

Yeah, sure. Let's just revert, and we take another stab at it along with support for __func__. Thanks! :)

JelleZijlstra added a commit that referenced this pull request Jan 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support __self__ on asynq'ed methods
2 participants