mutable-override does not understand unions

[kasium]

Bug Report
If I enable mutable-override it fails as it does not understand simple unions.

To Reproduce
Turn on mutable-override

class Base:
    val: bool|None = True
    
class Derived(Base):
    val = False

Gist: https://gist.github.com/mypy-play/aeec67e97957ea9e60431ce8466d8af3
Playground: https://mypy-play.net/?mypy=latest&python=3.12&enable-error-code=mutable-override&gist=aeec67e97957ea9e60431ce8466d8af3

Expected Behavior
no error

Actual Behavior

main.py:5: error: Covariant override of a mutable attribute (base class "Base" defined the type as "bool | None", expression has type "bool")  [mutable-override]
Found 1 error in 1 file (checked 1 source file)

Your Environment

• Mypy version used: 1.18.2
• Mypy command-line flags: enable-error-code="mutable-override"
• Python version used: 3.12

[A5rocks]

This isn't a mutable override issue, this is that mypy isn't using val's type in Base in Derived. This might be intended? If you override an attribute you probably expect it to narrow.

class Base:
    val: bool|None = True
    
class Derived(Base):
    val = False

reveal_type(Derived.val)  # N: Revealed type is "builtins.bool"

[A5rocks]

Yeah thinking about this just a little bit more, I think this is intentional. Think about this:

class A:
  def f(x: int) -> None:
    return None

class B(A):
  def f(x: object) -> None:
    return None

Wouldn't it be very annoying if B().f("str") errored? Because if we follow the logic that types inherit from parents, that's what happens. I think you should annotate that val: bool | None = False.

(Maybe someone disagrees with me, I will only add "pending" tag for now.)

[kasium]

I would say that your example should be flagged. But if I annotate something with X|Y than an assignment to X should not force me to duplicate the type hint

[A5rocks]

Should it? How about

x: X | Y = X()
class A:
  thing = x

class B(A):
  thing = X()

?

i.e. would you think it's important that the type hint is explicitly there? I don't think we currently have behavior anywhere like that...

[kasium]

good point. So even if you require type hints to be present (strict mode), the above code is fine. Do you know what mypy thinks behind the scenes, so that the error occurs?

[sterliakov]

It's sometimes annoying (I'd prefer no narrowing of inherited attributes by assignment at all, both for safety and for sanity), but it's typically easy to repeat the type hint.

Current behavior is most likely intended; we have a test asserting that.

Would be nice to stop such narrowing at least when mutable-override is enabled, but that can break even third-party dependencies types silently, so probably is infeasible.