concat still reports unreachable for Iterable[None|Any] corner case about pandas-stubs HOT 11 CLOSED

def foo2(df):
    return pd.DataFrame()

This declaration is incorrect. You call foo2() with no parameters, but you declare a parameter here.

So use

def foo2() -> pd.DataFrame:
    return pd.DataFrame()

and there is no problem.

from pandas-stubs.

The actual code is more complex, with the parameter actually being used. Let me see if I can come up with a more relevant example.

from pandas-stubs.

Ok. I simplified the example. I think it might be the destructuring that's the issue. The code now runs fine, but Pylance marks it unreachable. Understood that if I type the return list[pd.DataFrame | None] for the function, then no issues, but none of the code in my project is typed. Also, the actual function in my code can never return None. cc @Dr-Irv

from pandas-stubs.

Ok. I simplified the example. I think it might be the destructuring that's the issue. The code now runs fine, but Pylance marks it unreachable. Understood that if I type the return list[pd.DataFrame | None] for the function, then no issues, but none of the code in my project is typed. Also, the actual function in my code can never return None. cc @Dr-Irv

Not much we can do here. pylance is doing an analysis based on the stubs and inference of types that you haven't declared. It could be that their inference is incorrect. You're better off introducing types into your code so that pylance doesn't mark the code as unreachable.

I also put in your new example, and I'm not seeing the unreachable conclusion.

from pandas-stubs.

Ok. Thanks for looking anyway. Would you suggest I open an issue with Pylance? Here are my screenshots with the latest Pylance for the record.

So it is interpreting correctly as Iterable[None|Any]. Since you are not seeing the unreachable, does it mean panda-stubs handles the case, but Pylance doesn't?

from pandas-stubs.

Mirroring my code more closely (the accumulator var starts as None because it's a loop), I can definitely see an issue not related to anything pandas. Pylance thinks the code becomes unreachable within the loop, but then thinks things right outside the loop are fine... I'll open that issue over there.

from pandas-stubs.

One last relevant item for the record, the stub used by pylance:

from pandas-stubs.

Can you put this line in VSC: from pandas._version import _commit_hash then put your mouse over _commit_hash. If it doesn't appear, then you need to update pylance. I do think you're on an old version of the stubs.

from pandas-stubs.

from pandas-stubs.

So you're on the right version.

The type checking is inferring that df_new has an unknown type, and it seems that pylance is matching an unknown type to None. Here's an example that doesn't involve pandas that illustrates the issue you point out above (and makes it a pylance issue):

from typing import Literal
from typing_extensions import Never

def rlist():
    return [5, None]

def goo(x: Literal[None]) -> Never:
    raise Exception("not valid")

for _ in range(1):
    i, _ = rlist()
    goo(i)
    print("unreachable")
    
print("reachable")

Note that the yellow squiggles indicate where pylance can't infer the types (I have that turned on in my environment).

from pandas-stubs.

I would be open to removing the None->Never overload if it causes false negatives: we clearly can't catch similar bugs (empty lists).

from pandas-stubs.