isinstance is "tainting" a variable outside of conditional?

[dbushong]

https://pyright-play.net/?pythonVersion=3.14&strict=true&code=MYGwhgzhAEBCkFMBc0B06BQHSRgZQFcAjAbQBUBdACnggQEokNoXoAPFM51gTxSID2AkFgAmCAGbQJQqkUQpaDFOlRjJ0eQCcqAL0WJG3FgActASwB2AFyrmIViNbCXgCPQBpohIvWgvRaF1UHnpjaVldeiA

Basically: if you have a generic subclass, and (for runtime reasons), you do an isinstance() check (not qualifying the generic, as that's not valid), that somehow seems to taint the variable such that you can no longer use it in contexts that expect the base class:

class Base: ...

class Sub[T](Base):
    x: T
    y: bool

def foo(base: Base): ...

def bar(z: Base):
    print(isinstance(z, Sub) and z.y)
    foo(z)

produces this error on the last line:

Argument type is partially unknown
  Argument corresponds to parameter "base" in function "foo"
  Argument type is "Base | Sub[Unknown]"  (reportUnknownArgumentType)

Here's some confusing data points:

1. If you comment out the print(...) line, it no longer complains
2. If you remove the and z.y, it no longer complains
3. If you replace print() with if isinstance(...):, it still complains

Point 3 I can somewhat understand, even if I don't like it. We've now scoped z as a Sub[Unknown] and it doesn't like it. (I still feel we should be able to use it as a Base)

But in the current version, where just having done the isinstance() check at all it's erroring... that makes no sense to me.

To be clear, it's not the case that there's an implicit guard for z to be a Sub because otherwise z.y would error out, because and on the print line will short-circuit, so passing a Base in to bar() would work fine (at runtime), and so would passing in a hypothetical class Sub2(Base): ... instance.

[erictraut]

Yes, this is intended behavior.

The and operator (like the or operator) uses short-circuit evaluation, so they result in conditional code execution. To model this correctly, a type checker must build a code flow graph that includes a node with multiple successor branches — one that is an implicit "if" statement and the other that is an implicit "else" statement. Type narrowing needs to be applied for each of these branches. Your code is equivalent to this:

def bar(z: Base):
    if _v1 := isinstance(z, Sub):
        reveal_type(z)  # Sub[Unknown]
        _v1 = z.y
    else:
        reveal_type(z)  # Base
    reveal_type(z)  # Sub[Unknown] | Base
    print(_v1)

[dbushong]

1. (More importantly) What would, in your view, be the cleanest way to call foo(), in my example?
2. I find this extremely surprising behavior: that performing a non-mutating operation involving a variable would change the type of the variable outside of a visibly connected if/else clause. What benefit does this confer? Simpler examples:

def bar(z: Base):
    if isinstance(z, Sub):
        pass
    reveal_type(z)  # Sub[Unknown] | Base

vs

def bar(z: Base):
    print(isinstance(z, Sub))
    reveal_type(z)  # Base

[erictraut]

An if/elif/else statement isn't the only way that code can be conditionally executed. There are many other situations that can result in conditional branches within a code flow graph. This includes assert statements, while/else statements, try/except/else/finally statements, ternary operators, match statements, and/or shortcut evaluation, etc. A type checker needs to account for all of these cases, and it's best if it does so in a consistent manner. All conditional branches within a code flow graph can result in type narrowing.

I understand why you might find the behavior surprising at first blush, but if you think about it from the perspective of a code flow graph, you may find it less surprising.

Here's an (admittedly contrived) example of where the isinstance narrowing within an and expression can matter.

def bar(z: Base):
    print(not isinstance(z, Sub) and exit())
    return z.y

I don't know enough about the constraints of your problem to offer a recommendation for the cleanest approach here. Here's one potential approach: print(getattr(z, "y", False)).

In a former life, I managed a team at Microsoft with a large Python code base, and I advised my engineers not to make "overly clever" usage of and and or short-cut evaluation because it makes the code hard to read and can lead to subtle bugs. Maybe you don't find isinstance(z, Sub) and z.y "overly clever", but this is something I would have flagged in a code review.

One more consideration... your code sample type checks with no errors if you use pyright's default settings. You're seeing an error because you've enabled the reportUnknownArgumentType check, which is a strict-mode check. When you opt into strict-mode type checking, you should be prepared to make some modifications to your code to work with the type checker. If you don't find sufficient value from the strict-mode checks, you can leave them disabled (either collectively or individually).