-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Allow using modules as subtypes of protocols #13513
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
Conversation
This comment has been minimized.
This comment has been minimized.
Hm, those few errors are clearly wrong, and I know where they are coming from. Will try to fix now. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Yes, I think both should be errors. I will add tests later today (and update implementation if needed). |
@sobolevn OK, I added test and fixed code. Btw I discovered that we didn't do the final check for normal instances either, so I fixed that as well (I actually even found an issue about this on the tracker). |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
You rock! Also thank you to the reviewers. |
Got some free time on my paternity leave :-) |
Oh congratulations! |
Thank you! |
Fixes #5018
Fixes #5439
Fixes #10850
The implementation is simple but not the most beautiful one. I simply add a new slot to the
Instance
class that represents content of the module. This new attribute is short lived (it is not serialized, and not even stored on variables etc., because we erase it incopy_modified()
). We don't need to store it, because all the information we need is already available inMypyFile
node. We just need the new attribute to communicate between the checker andsubtypes.py
.Other possible alternatives like introducing new dedicated
ModuleType
, or passing the symbol tables tosubtypes.py
both look way to complicated. Another argument in favor of this new slot is it could be useful for other things, likehasattr()
support and ad hoc callable attributes (btw I am already working on the former).Note there is one important limitation: since we don't store the module information, we can't support module objects stored in nested positions, like
self.mods = (foo, bar)
and thenaccepts_protocol(self.mods[0])
. We only support variables (name expressions) and direct instance, class, or module attributes (see tests). I think this will cover 99% of possible use-cases.