-
-
Notifications
You must be signed in to change notification settings - Fork 3k
Protocols with property descriptors require all compliant symbols to use the same implementation. #9202
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
Labels
topic-descriptors
Properties, class vs. instance attributes
Comments
Would not surprise me if this was effectively the same problem as #7153, but here the issue is with how to define a Protocol. |
I was hit today by this as well. It seems there is no way to define read only attribute in protocol, which in concrete implementation can be property, custom descriptor or standard field. I'm using mypy 1.0.1. Request for defining read only attribute was also raised in #6002. |
cdce8p
pushed a commit
to cdce8p/mypy
that referenced
this issue
May 31, 2025
Fixes python#18024 Fixes python#18706 Fixes python#17734 Fixes python#15097 Fixes python#14814 Fixes python#14806 Fixes python#14259 Fixes python#13041 Fixes python#11993 Fixes python#9585 Fixes python#9266 Fixes python#9202 Fixes python#5481 This is a fourth "major" PR toward python#7724. This is one is watershed/crux of the whole series (but to set correct expectations, there are almost a dozen smaller follow-up/clean-up PRs in the pipeline). The core of the idea is to set current type-checker as part of the global state. There are however some details: * There are cases where we call `is_subtype()` before type-checking. For now, I fall back to old logic in this cases. In follow up PRs we may switch to using type-checker instances before type checking phase (this requires some care). * This increases typeops import cycle by a few modules, but unfortunately this is inevitable. * This PR increases potential for infinite recursion in protocols. To mitigate I add: one legitimate fix for `__call__`, and one temporary hack for `freshen_all_functions_type_vars` (to reduce performance impact). * Finally I change semantics for method access on class objects to match the one in old `find_member()`. Now we will expand type by instance, so we have something like this: ```python class B(Generic[T]): def foo(self, x: T) -> T: ... class C(B[str]): ... reveal_type(C.foo) # def (self: B[str], x: str) -> str ``` FWIW, I am not even 100% sure this is correct, it seems to me we _may_ keep the method generic. But in any case what we do currently is definitely wrong (we infer a _non-generic_ `def (x: T) -> T`). --------- Co-authored-by: hauntsaninja <[email protected]> Co-authored-by: Shantanu <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug.
or a mock-up repro if the source is private. We would appreciate
if you try to simplify your case to a minimal repro.
Code snippet attached at end of report.
It appears to be not possible to define a Protocol describing an object that has an attribute named "prop1" with type "int".
Any attempt to do so binds the resulting protocol to the implementation chosen in defining the protocol (i.e. must use the same property/descriptor type).
No errors should be reported.
mypy == 0.770 , Python=3.8.4.
None.
The text was updated successfully, but these errors were encountered: