"already defined" errors when adding type annotations in multiple code paths

[timabbott]

While trying to debug something, I ended up adding type annotations for the definitions of an object in both code paths, and got a /home/tabbott/foo.py:10: error: Name 'child_pid' already defined with this (simplified) code:

if True:
    child_pid = os.fork() # type: int
    # Do stuff
else:
    child_pid = None # type: int

Since the types are the same, it seems like this shouldn't be an error.

This may be a variant of #1153.

[gvanrossum]

Hm, I think mypy actually has an intentional rule that you shouldn't annotate a variable twice, and I like that rule. So I am tempted to reject this one. The right fix would be to make the first annotation Optional[int].

[JukkaL]

Yeah, this is by design.

[JukkaL]

Closing this now. Feel free to reopen if you don't agree :-)

[ruuda]

Somewhat related, this error also triggers even when del is used:

if True:  # For example, should not be const in practice.
    foo: int = 0
    print(foo)
    del foo
else:
    foo: int = 0
    print(foo)

In the following example it even reports an error: "Trying to read deleted variable 'foo'" on the last line.

if True:  # For example, should not be const in practice.
    foo: int = 0
    print(foo)
    del foo

foo: int = 0
print(foo)

I am using Mypy 0.610.

[gvanrossum]

There should be only one declaration of a given variable per scope. And a function is one scope.

[impredicative]

There should be only one declaration of a given variable per scope.

This recommendations seems wholly unreasonable. Python itself has no such restriction. I feel lousy having to change my variable names just to make mypy happy.

[gvanrossum]

We are actively working on this restriction.

[JukkaL]

The initial implementation will likely only cover redefinition within a single block at the same nesting level, but it's possible that we'll extend it to handle other cases in the future.

[komuw]

The initial implementation will likely only cover redefinition within a single block

@JukkaL should this github issue be re-opened?

I just ran into this is in my code.

import typing, logging

def convertLog(log_level: typing.Union[str, int]) -> int:
    """
    usage:
       level = convertLog(log_level="DEBUG") 
       assert level == 10
    """
    if isinstance(log_level, str):
        log_level: int = logging._nameToLevel[log_level.upper()]
    return log_level

mypy complains about log_level already defined.
However, do note that a log_level enters the function either as an int or a str but can only come out as an int

[ilevkivskyi]

@komuw You can simply remove that : int annotation, it is just not needed there.

[bela127]

Same Problem in the flowing to implementations
Note that implementation 2 is the way of annotating for loops per pep

so it definitely should be supported to have for loops with different types for the running variable

class Functionality():
   
    def __init__(self: Functionality, func: Callable[Info,Any]):
        super().__init__()
        self.func: Callable[Info,Any] = func
        self.pre_call: List[PreExpert] = []
        self.post_call: List[PostExpert] = []
        
    def __call__(self: Functionality, info):
      
        for expert in self.pre_call:
            if expert.can_work_with(info):
                expert.execute(info)
        
        ret = self.func(info)

        for expert in self.post_call:                    ##Problem
            if expert.can_work_with(info):
                expert.execute(info)
                
        return ret

class Functionality():
   
    def __init__(self: Functionality, func: Callable[Info,Any]):
        super().__init__()
        self.func: Callable[Info,Any] = func
        self.pre_call: List[PreExpert] = []
        self.post_call: List[PostExpert] = []
        
    def __call__(self: Functionality, info):
        expert: PreExpert
        for expert in self.pre_call:
            if expert.can_work_with(info):
                expert.execute(info)
        
        ret = self.func(info)
        
        expert: PostExpert  ##Problem
        for expert in self.post_call:
            if expert.can_work_with(info):
                expert.execute(info)
                
        return ret

[JukkaL]

You can try --allow-redefinition -- it will let you redefine some variables (though not always).

[DevilXD]

I'm having an issue where this redefinition check ignores pathways that will never happen at runtime, for example where the code takes a path after an if check, that ends with a return. Simplified example:

key: Union[int, str]

if isinstance(key, int):
    ...
    result: Tuple[int, str] = ...
    ...
    return result
...  # here the type of 'key' is 'str' only
result: Tuple[int, str] = ...  # here is the redefinition error, pointing at the line inside the if check above as the original definition
...
return result

[cipollone]

I'm fine with the rule "only one annotation per scope". To me, the problem is just that the error is not informative enough. Both the error text and the example in the documentation suggest that it may be a coding issue. Instead, I just had to remove the second annotation!

if not resuming:
  # Initialize
  obj = MyClass()
else:
  # Load back
  obj: MyClass = loader.deserialize()

Without this github issue I couldn't figure out what was wrong.

[JulesGM]

any progress on removing the prohibition of declaring the same variable multiple times? this is annoying, should be left to the user

[parhamfh]

Stumbled upon this as well, perhaps if this is helpful to some but not to others it could be turned into a warning instead. This feels like checking code style.

[bafulton]

I just stumbled onto this now. I agree with @JulesGM and @parhamfh --this feels too prescriptive to me. I'd be in favor of making it a warning.