8000 Fix inference for overloaded __call__ with generic self by hauntsaninja · Pull Request #16053 · python/mypy · GitHub
[go: up one dir, main page]
Skip to content

Fix inference for overloaded __call__ with generic self #16053

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.

Sign up for GitHub

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 15 commits into from
Sep 19, 2023
Merged

Fix inference for overloaded __call__ with generic self #16053

Changes from 1 commit
Commits
Show all changes
15 commits
Select commit Hold shift + click to select a range
2f12b60
Fix inference for overloaded __call__ with generic self
hauntsaninja Sep 5, 2023
a2abbb6
undo lazy hack
hauntsaninja Sep 14, 2023
98b4b30
Merge remote-tracking branch 'upstream/master' into generic-call
hauntsaninja Sep 14, 2023
d5431e1
regression test
hauntsaninja Sep 15, 2023
c36efdd
new, bad test
hauntsaninja Sep 15, 2023
89fc492
fix for non-generic callable tuple subclasses
hauntsaninja Sep 15, 2023
45a7851
Merge remote-tracking branch 'upstream/master' into generic-call
hauntsaninja Sep 15, 2023
9a776cf
fix
hauntsaninja Sep 15, 2023
844826c
check fallback args
hauntsaninja Sep 15, 2023
8004705
unnecessary if
hauntsaninja Sep 15, 2023
4499906
comment
hauntsaninja Sep 15, 2023
54187d1
remove my fix for callable generic tuple subclasses
hauntsaninja Sep 17, 2023
1d959c3
ilevkivskyi fix
hauntsaninja Sep 17, 2023
b3aa066
subtype fixes
hauntsaninja Sep 17, 2023
ca4c294
break
hauntsaninja Sep 19, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next Next commit
Fix inference for overloaded __call__ with generic self 
Fixes #8283
  • Loading branch information
@hauntsaninja
hauntsaninja committed Sep 5, 2023
commit 2f12b603cd72c464164d2781f3315d823314e196
15 changes: 7 additions & 8 deletions mypy/checkmember.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -330,13 +330,12 @@ def analyze_instance_member_access(
signature = method.type
signature = freshen_all_functions_type_vars(signature)
if not method.is_static:
if name != "__call__":
# TODO: use proper treatment of special methods on unions instead
# of this hack here and below (i.e. mx.self_type).
dispatched_type = meet.meet_types(mx.original_type, typ)
signature = check_self_arg(
signature, dispatched_type, method.is_class, mx.context, name, mx.msg
)
# TODO: use proper treatment of special methods on unions instead
# of this hack here and below (i.e. mx.self_type).
dispatched_type = meet.meet_types(mx.original_type, typ)
signature = check_self_arg(
signature, dispatched_type, method.is_class, mx.context, name, mx.msg
)
signature = bind_self(signature, mx.self_type, is_classmethod=method.is_class)
# TODO: should we skip these steps for static methods as well?
# Since generic static methods should not be allowed.
Expand Down Expand Up @@ -898,7 +897,7 @@ def f(self: S) -> T: ...
selfarg = get_proper_type(item.arg_types[0])
if subtypes.is_subtype(dispatched_arg_type, erase_typevars(erase_to_bound(selfarg))):
new_items.append(item)
elif isinstance(selfarg, ParamSpecType):
elif isinstance(selfarg, (ParamSpecType, TupleType)):
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Bit of a lazy hack to keep testTypeTupleCall and testTypeNamedTupleCall green

Copy link
Member

Choose a reason for hiding this comment

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

This looks suspicious. ParamSpecType doesn't really make sense here (and it is unlikely it can get there without previously emitting an error), but TupleType is relatively common self-type for various user defined tuple types. Is it needed because type erasure touches some unhandled/incorectly handled corner case in is_subtype()? If yes, then that should be fixed instead.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yeah, needs a change in is_subtype: #16073

# TODO: This is not always right. What's the most reasonable thing to do here?
new_items.append(item)
elif isinstance(selfarg, TypeVarTupleType):
Expand Down
0