False negative involving partial assignment and walrus #22262

Activity

1. hauntsaninja

   added

   bugmypy got something wrongmypy got something wrong

   on Oct 21, 2026
2. hauntsaninja

   changed the title [-]False negative involving partial assignment[/-] [+]False negative involving partial assignment and walrus[/+] on Oct 21, 2026
3. DipanshuAmbilkar03 commented on Oct 28, 2026

   

   DipanshuAmbilkar03

   on Oct 28, 2026

   More actions

   I traced this one:

   • x = None puts x in a partial None type.
   • While the rvalue is checked, the walrus resolves that partial type, so x is inferred as int | None and the variable is removed from the partial type scope.
   • Back in check_assignment() for the outer statement, find_partial_types() returns nothing, so the tuple assignment skips the regular compatibility check, and the binder keeps the type of the nested assignment (int) instead of the type of the statement.

   A small fix is to check the outer rvalue against the type that was already inferred in that case. That makes this snippet report an incompatible assignment, which is what mypy already does for the equivalent code without the walrus:

   x = None
   x = 1
   x = (x, 1)  # Incompatible types in assignment (tuple[int, int] vs int | None)

   I saw that #22282 tried this and was closed, so before opening another PR: is that direction acceptable, or would you prefer this to be handled by the type-context work, where an rvalue containing a walrus and checked twice would accumulate the type assignments instead (the TODO in infer_rvalue_with_fallback_context)? Happy to write a test-only PR in the meantime if that is more useful.