FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

Do not cache fast container types inside lambdas by sterliakov · Pull Request #20166 · python/mypy · GitHub

Repository navigation

Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension .py  (1) .test  (1) All 2 file types selected
Viewed files
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Unified
Split
Hide whitespace
Diff view
Unified
Split
Hide whitespace
10 changes: 8 additions & 2 deletions mypy/checkexpr.py
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Original file line number Diff line number Diff line change
Expand Up @@ -5082,7 +5082,10 @@ def fast_container_type(
self.resolved_type[e] = NoneType()
return None
ct = self.chk.named_generic_type(container_fullname, [vt])
self.resolved_type[e] = ct
if not self.in_lambda_expr:
# We cannot cache results in lambdas - their bodies can be accepted in
# error-suppressing watchers too early
self.resolved_type[e] = ct

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Isn't there an expr cache that stores errors too? Is it possible to use that instead?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

We already explicitly bypass the expr cache for lambdas, so probably no?

mypy/mypy/checkexpr.py

Lines 6035 to 6050 in 843d133

elif (
isinstance(node, (CallExpr, ListExpr, TupleExpr, DictExpr, OpExpr))
and not (self.in_lambda_expr or self.chk.current_node_deferred)
and not self.chk.options.disable_expression_cache
):
if (node, type_context) in self.expr_cache:
binder_version, typ, messages, type_map = self.expr_cache[(node, type_context)]
if binder_version == self.chk.binder.version:
self.chk.store_types(type_map)
self.msg.add_errors(messages)
else:
typ = self.accept_maybe_cache(node, type_context=type_context)
else:
typ = self.accept_maybe_cache(node, type_context=type_context)
else:
typ = node.accept(self)

A5rocks Nov 3, 2025 •
edited
Loading

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

That makes some sense, but I don't quite get the comment there. I also don't get why this extra cache exists...

I guess the comment is saying "the same expr can be evaluated multiple times in different contexts" which makes a bit of sense?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

I also do not fully understand why a separate resolved_type storage is needed at all. It might well be just a remainder that wasn't cleaned up when expr_cache was introduced, but I'm not certain.

This lambda special-casing is coming from in #19408 and #19505, we discovered it independently. lambda exprs are handled in a completely different way with and without type context (see infer_lambda_type_using_context and branching on its result). There's a big difference between accepting a ReturnStmt and its expression alone - supporting both ways essentially means that we use different context stack entries on different paths for the same expression. This part is a bit difficult to reason about, but I still hope I got it correctly...

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

OK, I guess it would make sense to try removing resolved_type cache in a followup...

return ct

def _first_or_join_fast_item(self, items: list[Type]) -> Type | None:
Expand Down Expand Up @@ -5317,7 +5320,10 @@ def fast_dict_type(self, e: DictExpr) -> Type | None:
self.resolved_type[e] = NoneType()
return None
dt = self.chk.named_generic_type("builtins.dict", [kt, vt])
self.resolved_type[e] = dt
if not self.in_lambda_expr:
# We cannot cache results in lambdas - their bodies can be accepted in
# error-suppressing watchers too early
self.resolved_type[e] = dt
return dt

def check_typeddict_literal_in_context(
Expand Down
14 changes: 14 additions & 0 deletions test-data/unit/check-inference-context.test
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Original file line number Diff line number Diff line change
Expand Up @@ -709,6 +709,20 @@ f(
A(), r=B())
[builtins fixtures/isinstance.pyi]

[case testLambdaWithFastContainerType]
from collections.abc import Callable
from typing import Never, TypeVar

T = TypeVar("T")

def f(a: Callable[[], T]) -> None: ...

def foo(x: str) -> Never: ...

f(lambda: [foo(0)]) # E: Argument 1 to "foo" has incompatible type "int"; expected "str"
f(lambda: {"x": foo(0)}) # E: Argument 1 to "foo" has incompatible type "int"; expected "str"
[builtins fixtures/tuple.pyi]


-- Overloads + generic functions
-- -----------------------------
Expand Down

Back | FazBrowse Home | New Git URL