Skip to content

TYP: fix ignores #40412

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Mar 13, 2021
Merged

Conversation

jbrockmendel
Copy link
Member

cc @simonjayhawkins

Locally when I run mypy on master I get 427 errors mostly "unused 'type: ignore' comment". Same result when i switch from py39 to py38, or from OSX to Ubuntu. mypy==0.812 in all cases. Any guesses what config the CI has different?

@simonjayhawkins
Copy link
Member

Locally when I run mypy on master I get 427 errors mostly "unused 'type: ignore' comment". Same result when i switch from py39 to py38, or from OSX to Ubuntu. mypy==0.812 in all cases. Any guesses what config the CI has different?

can you confirm that you have numpy 1.20.1 in those envs.

arr = com.asarray_tuplesafe(
data, dtype=object # type: ignore[arg-type]
)
arr = com.asarray_tuplesafe(data, dtype=np.dtype("object"))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do not change but I think dtype should be the string version to satisfy the typing in asarray_tuplesafe since not sure if there are perf issues that will accumulate creating a dtype object unnecessarily. but there does look like there may be an issue in asarray_tuplesafe since "object" in [np.object_, object] is False so the type annotations for asarray_tuplesafe maybe incorrect.

side note:

I think that we want to import the numpy type definitions for dtype in pandas._typing

in asarray_tuplesafe we use NpDtype from pandas._typing, which is not as permissive as the numpy alias, or what is actually accepted by numpy for dtype arguments (with the exception of object which is a false positive but is a special case since it creates issues with static typing)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since not sure if there are perf issues that will accumulate creating a dtype object unnecessarily

my thought is that these will have to be converted to np.dtype objects somewhere in the call stack, so should be roughly perf neutral. no actual measurements on that though.

# error: Incompatible types in assignment (expression has type
# "str", variable has type "Union[dtype[Any], ExtensionDtype]")
dtype = "float64" # type: ignore[assignment]
dtype = np.dtype("float64")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dtype is passed to astype which accepts a string? i'm not convinced this is the best approach to removing the ignores. maybe could add a type variable declaration to dtype = find_common_type(... to avoid the Incompatible types in assignment... error.

@simonjayhawkins simonjayhawkins added the Typing type annotations, mypy/pyright type checking label Mar 13, 2021
@simonjayhawkins simonjayhawkins added this to the 1.3 milestone Mar 13, 2021
Copy link
Member

@simonjayhawkins simonjayhawkins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jbrockmendel. In general, I prefer not to change code to appease mypy but i'll defer to you on this assessment.

@simonjayhawkins simonjayhawkins merged commit 548f44f into pandas-dev:master Mar 13, 2021
@jbrockmendel
Copy link
Member Author

can you confirm that you have numpy 1.20.1 in those envs.

that fixed it, thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Typing type annotations, mypy/pyright type checking
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants