mypy caches types of attributes for too long, ignoring side effects of methods #14010

Activity

1. finite-state-machine

   added

   bugmypy got something wrongmypy got something wrong

   on Nov 4, 2022
2. Avasam commented on Nov 4, 2022

   

   Avasam

   on Nov 4, 2022

   Last edited by Avasam

   SponsorContributor

   More actions

   Not sure it could even analyze that statically (in more complex cases) because of the mutation.
   You can, however, decide to never typeguard directly on your mutated property. This way mypy and pyright will keep seeing it as a bool.

   from typing_extensions import reveal_type
   
   class SomeClass:
   
       cache_hot: bool = False
   
       def some_method(self) -> None:
           # expensive computation goes here
           self.cache_hot = True
   
   
   def test_some_class() -> None:
   
       instance = SomeClass()
       cache_hot = instance.cache_hot
       assert not cache_hot
   
       instance.some_method()
   
       cache_hot = instance.cache_hot
       reveal_type(cache_hot)
       assert cache_hot
   
       assert isinstance(instance, SomeClass)

   👍React with 👍1Reacted by Finite State Machine
3. hauntsaninja commented on Nov 4, 2022

   

   hauntsaninja

   on Nov 4, 2022

   Collaborator

   More actions

   Yeah, this is a heuristic mypy uses that is needed in practice. Other type checkers do this too. Would need some complicated type system feature to make this expressible.

   There are a couple workarounds, but one good one is a dummy re-assignment instance = instance

   👍React with 👍1Reacted by Finite State Machine
4. hauntsaninja

   closed this as not plannedon Nov 4, 2022
5. finite-state-machine commented on Nov 4, 2022

   

   finite-state-machine

   on Nov 4, 2022

   Author

   More actions

   I agree this would be very difficult to definitively fix, but I was surprised I couldn't find an issue (open or closed) describing this problem or ways to work around it.

   @Avasam @hauntsaninja thank you both for the very helpful suggestions!
6. finite-state-machine commented on Nov 5, 2022

   

   finite-state-machine

   on Nov 5, 2022

   Author

   More actions

   I wonder: for the benefit of others who encounter this issue in future, is there some way to make this thread (or the gist of it) easier to find? I anticipate most people won't search for closed issues.
7. ShadowLNC commented on Dec 3, 2022

   

   ShadowLNC

   on Dec 3, 2022

   More actions

   Yeah this issue is difficult to find, I nearly ended up creating a duplicate.
   Interestingly upgrading from mypy version 0.910 to 0.991 and from Python 3.8 to 3.11 caused some similar issues for us - we're getting a false positive about Statement is unreachable too.

   This self-contained example does the same thing (although I know mypy struggles with @property sometimes):

   import time
   
   
   class X:
       start: float
   
       def __init__(self) -> None:
           self.start = time.time()
   
       @property
       def has_time_passed(self) -> bool:
           return (time.time() - self.start) >= 3
   
       def sleep(self) -> None:
           time.sleep(3)
   
   
   val = X()
   assert not val.has_time_passed, "..."
   val.sleep()
   assert val.has_time_passed, "..."
   assert val.has_time_passed, "..."

   Our actual code is slightly more complex of the form:

   assert not x.some_prop, "..."
   assert not y.some_prop, "..."
   assert not z.some_prop, "..."
   
   x.some_func("...", y.other_prop, z.other_prop)
   assert x.some_prop, "..."
   # Flagged as unreachable, all 3 statements here assume `some_prop` is `false`.
   assert y.some_prop, "..."
   assert z.some_prop, "..."

   I find it a little strange that it didn't previously narrow this type (Python 3.8, mypy 0.910) and I'm not sure when it changed given how many releases have happened since then. In any case, the upgrade has fixed some of our other type: ignore statements, so on balance I think it's still a win 😄

   👍React with 👍1Reacted by Finite State Machine
8. sterliakov

   marked False positive comparison-overlap #15509 as a duplicate of this issue on Sep 7, 2025