Skip to content

Support decorated constructors #6645

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

Merged
merged 5 commits into from
Apr 27, 2019
Merged

Conversation

ilevkivskyi
Copy link
Member

Fixes #1706
Fixes #5398

Previously, decorated constructors either resulted in silent Any types for class objects (in case of a decorated __init__()) or incorrect signatures (in case of a decorated __new__()).

This PR adds support for decorated constructors, implementation is straightforward.

This PR supersedes #5798.

@gvanrossum
Copy link
Member

I'm sorry, I don't think I can review this.

Copy link
Collaborator

@msullivan msullivan left a comment

Choose a reason for hiding this comment

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

This looks good!

How much damage does it cause for internal codebases?


def type_object_type_from_function(init_or_new: FuncBase,
This includes nomral functions, overloaded functions, and decorators
Copy link
Collaborator

Choose a reason for hiding this comment

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

typo - "nomral"

else:
assert isinstance(method.type, FunctionLike) # is_valid_constructor() ensures this
t = method.type
signature = bind_self(t)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Any particular reason for moving this bind_self out of type_object_type_from_function? I don't have any objection, I'm just wondering if there is a technical reason I'm missing or you just like it more.

Copy link
Member Author

Choose a reason for hiding this comment

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

No particular reason. I think I started refactoring by pulling function_type() out of there, and pulled whole line out of there. But looking again at it I think it makes sense to keep bind and map together, so I will put it back.

@ilevkivskyi
Copy link
Member Author

How much damage does it cause for internal codebases?

Not so much actually, around 60 errors S+C.

@ilevkivskyi ilevkivskyi merged commit b778c87 into python:master Apr 27, 2019
@ilevkivskyi ilevkivskyi deleted the fix-deco-init branch April 27, 2019 01:42
msullivan added a commit that referenced this pull request Apr 27, 2019
PR #6645 introduced a mypyc failure due to the irritating #3603
intersection type issue.

Fix it by testing again SYMBOL_FUNCBASE_TYPES instead of FuncBase
@msullivan msullivan mentioned this pull request Apr 27, 2019
ilevkivskyi pushed a commit that referenced this pull request Apr 27, 2019
PR #6645 introduced a mypyc failure due to the irritating #3603
intersection type issue.

Fix it by testing again SYMBOL_FUNCBASE_TYPES instead of FuncBase
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.

Decorator on __init__ causes loss of type info Adding @abstractmethod __init__ to ABC breaks staticmethods
3 participants