Unbound variable detection seems off

[apparebit]

Lest is misclassify my issue, I figured I start a discussion first. Consider this minimal snippet representing more complicated code:

def fn() -> int:
    for i in (665,):
        pass
    return i

When I put on my type checker hat, I determine that the tuple literal ensures at least one loop iteration and hence I is initialized. I also determine that the loop variable iterates over a tuple[int,...] and hence its type is compatible with the function's return type. Yay!

However, pyright claims the I is "possibly unbound." I don't think I'm missing something (especially after reducing the real code to the above snippet). That's disappointing because any alternative that might satisfy the type checker, i.e., an explicit declaration before the loop as suggested in similar cases before, adds a line and then I have to deal with None as well, which all seems a bit excessive.

So, bug or feature request? 😇

[erictraut]

Pyright is working as designed here, so I don't consider this a bug.

In general, a type checker cannot determine the number of times that an iterable will return a value. In this very specific example, it is possible to determine this statically, but making this specific case work would be difficult and costly from a type analysis performance standpoint. Pyright's "unbound variable" detection logic is based on a code flow graph, which is necessarily built prior to any type analysis — long before it can analyze the type of the iterable in the for ... in statement. So this case would require building conditional nodes into the code flow graph, and this would likewise create additional dependencies between symbols when walking the code flow graph. This could have a measurable impact on analysis performance for all for loops.

I think there's a way I could make this work, but it would add complexity and overhead that would be justified only if this were sufficiently important to enough pyright users. Since you're the first person (as far as I remember) to request this support, I don't think it's justified at this time. We can leave this discussion topic open to see if it gets additional upvotes (in the form of thumbs-up reactions). If the signal is sufficiently strong, I might consider adding the feature.

In general, I recommend against using loop iteration variables outside of a loop. Most modern programming languages forbid this — and for good reason. Python's lax variable scoping rules don't prevent this, but that doesn't mean that it's a good programming practice.

[apparebit]

Thanks for the background on why integrating such a feature into pyright would be difficult. That was genuinely interesting and explains a lot.

However, I disagree with your last paragraph. It seems that we end up with the worst of all worlds if we just adopt coding practices from contemporary strongly typed languages. We lose the benefits of dynamism yet also can't really write great typed code because the type systems just aren't strong enough.

That tension has been the source of major frustration for me of late in the demicode project. As I'm trying to get rid of boilerplate code and making support for Unicode Character Database properties truly generic, I keep running into situations where I can write it and it works, but I can't type it or only with ugly work-arounds. The above is only a small example and I can live with that one not being possible. But in other places, that's becoming a show stopper because I see no good way of resolving this tension. Note to self: distill challenges and bring them here.

Thank you, @erictraut, for the quick turn-around and the helpful answer!

[erictraut]

To be clear, the recommendation I made above has nothing to do with typing. Even in untyped languages, I contend that it's a bad idea to use a loop iteration variable after the loop. In my experience, this makes the code harder to follow and can lead to bugs and maintenance issues. Languages like Javascript (which does not have a static type system) disallow access to a loop iteration variable outside of the loop.

function func() {
    for (let i = 0; i < 10; i++) {
        console.log(i);
    }
    console.log(i); // Error: i is out of scope
}

I understand what you're saying about the tension between static type checking and the dynamism of the language. As with many things in life, it's a tradeoff. Thankfully, the static type system in Python allows for gradual typing and provides many "escape hatches" if you want to use the more dynamic aspects of the language. Of course, when you do this, you give up some protections that are otherwise afforded by static type checks.