python / python/mypy

Variable assigned in branches of an if statement is considered as being redefined

Open
#17,529 2 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
Python
Stars
20.6k
Forks
3.3k
PR merge metrics
PR metrics pending

Description

Bug Report

The same variable assigned in different branches of an if statement is considered as being redefined, despite the fact that at in reality there is only one assignment being performed, it's just unknown at that stage which branch will be taken.

To Reproduce

from io import BytesIO
from typing import ClassVar

class IntegerAdapter:
    _size_: ClassVar[int] = 4

    @classmethod
    def from_wire(cls, buffer: bytes | bytearray | memoryview | BytesIO) -> int:
        if isinstance(buffer, BytesIO):
            data = buffer.read(cls._size_)
        else:
            data = buffer[:cls._size_]
        return int.from_bytes(data, byteorder='big', signed=True)

Expected Behavior

I would expect mypy to infer the type of the variable as the union of the types in all branches. This is not really a redefinition since the variable is not assigned twice in succession, only one branch is taken, it's just unknown which one.
Using --allow-redefinition doesn't help as one of the requirements for that is to read the variable before the next assignment, which is impossible.

Also the behavior is inconsistent with different ways of writing the if statement. Inverting the condition and reversing the branches makes the error go away. So does using an equivalent conditional expression.

Any of the following ways to rewrite the if statement will eliminate the error, but one should not have to retort to such gimmicks to avoid this.

        # this works because the 1st assignment is the one with a wider type that includes the type of the 2nd
        if not isinstance(buffer, BytesIO):
            data = buffer[:cls._size_]
        else:
            data = buffer.read(cls._size)

        # this works because the type is correctly inferred to be the union of the branch types
        data = buffer.read(cls._size_) if isinstance(buffer, BytesIO) else buffer[:cls._size_]

IMO the conditional statement is the only one that behaves correctly here as it infers the type as the union of the two.
But semantically the if-else and the conditional statement are the same, just differently written: take one branch and assign computed value to the variable.

Actual Behavior

typing-6.py:14: error: Incompatible types in assignment (expression has type "bytes | bytearray | memoryview", variable has type "bytes")  [assignment]
Found 1 error in 1 file (checked 1 source file)

Your Environment

  • Mypy version used: mypy 1.12.0+dev.6a0657e5959ba1777c4d427f8f355d499035d145 (compiled: no)
  • Mypy command-line flags: with or without --allow-redefinition, makes no difference
  • Mypy configuration options from mypy.ini (and other config files):
[tool.mypy]
enable_incomplete_feature = "NewGenericSyntax"
disable_bytearray_promotion = true
disable_memoryview_promotion = true
check_untyped_defs = true
warn_unreachable = true
warn_redundant_casts = true
warn_unused_ignores = true
  • Python version used: 3.12

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by running the supplied Python reproducer with mypy and the shown configuration, comparing the if-else form with the equivalent conditional expression. Trace how branch assignments are checked and make the if-else case infer the union without reporting an incompatible redefinition; verify the reproducer completes with no error.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.