TYP: pd.isna

[twoertwein]

Inferred by mypy and pyright:

import numpy as np
import pandas as pd

class A:
    ...

# bool
reveal_type(pd.isna(1))

# npt.NDArray[np.bool_]
reveal_type(pd.isna([]))
reveal_type(pd.isna(np.zeros(3)))
reveal_type(pd.isna(pd.DatetimeIndex([None])))

# pd.DataFrame
reveal_type(pd.isna(pd.DataFrame()))

# pd.Series
reveal_type(pd.isna(pd.Series()))

# Union of all possible cases
reveal_type(pd.isna(A())) # should be bool

[Dr-Irv]

Would you mind not force pushing the branch in the future? It makes it hard to see what changes you made in just the last commit.

[twoertwein]

Would you mind not force pushing the branch in the future? It makes it hard to see what changes you made in just the last commit.

Okay. was rebasing on main (git pull --rebase main) but kept the new commit separate.

[Dr-Irv]

one small comment

[Dr-Irv]

Would you mind not force pushing the branch in the future? It makes it hard to see what changes you made in just the last commit.

Okay. was rebasing on main (git pull --rebase main) but kept the new commit separate.

I just do

git fetch upstream
git merge upstream/main
git add the_files_I_changed
git commit -m "why I changed those files"
git push origin mybranch

That seems to make it easier to track things for others.

[Dr-Irv]

one small grammatical change

[Dr-Irv]

@twoertwein I approved, but I think @simonjayhawkins or @jbrockmendel should take a look as well.

[jreback]

@twoertwein if you can merge master

[twoertwein]

green, except for mypy error also present on main

[jreback]

thanks @twoertwein

[simonjayhawkins]

Thanks @twoertwein for the PR.

I didn't want to comment on this PR before to avoid "too many cooks" and in general if mypy is happy, so am I. (In some respects, because we have mypy we don't need to review certain aspects of typing as if it is not 100% correct, it will create issues down the line. I see it like a jigsaw puzzle that won't be complete until the last piece is in place, i.e. the codebase is 100% typed.)

However, I think I've seen that your preference is to import from pandas._typing inside the TYPE_CHECKING also elsewhere? If this is correct can you explain the reasoning so that it helps when reviewing other contributors PRs.

AFAIK, we ensure all imports in pandas._typing are guarded so that they can be imported at the top level and for instance npt was added so that we could import without needing to add a TYPE_CHECKING block everywhere it was needed, otherwise we would just import from numpy directly and not include in pandas._typing?

[twoertwein]

Good point! I imported it within the TYPE_CHECKING block because it is only needed for type checking . I will import it outside the TYPE_CHECKING block in next PRs.

Probably one reason why I prefer to put imports in this block is that there are some import cycles that prevent even mypy to function correctly: I think having from pandas import Index caused issues whereas from pandas.core.indexes.base import Index worked without issues (both inside the TYPE_CHECKING block).

[simonjayhawkins]

Yes, for import cycles it is definitely needed. My preference is also adding imports inside the type checking if added specifically in a typing PR for type annotations but this is difficult to enforce since say a refactor could remove the need for a top level import and it would not be removed because it is still used in type annotations then in theory the import should be moved to the type checking for consistency.

[simonjayhawkins]

I think having from pandas import Index caused issues whereas from pandas.core.indexes.base import Index worked without issues (both inside the TYPE_CHECKING block).

my preference here is to use from pandas import Index when inside the type checking block. less typing! (the fingers on the keyboard type of typing not the type annotations type of typing!)

[twoertwein]

I just tried replacing it with from pandas import Index and it worked, must have been something different that caused weird mypy issues.