Skip to content

CLN refactor maybe-castable #39257

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 4 commits into from
Feb 7, 2021
Merged

Conversation

MarcoGorelli
Copy link
Member

  • Ensure all linting tests pass, see here for how to run them

extracted from #37586

@@ -1301,20 +1301,18 @@ def convert_dtypes(
return inferred_dtype


def maybe_castable(arr: np.ndarray) -> bool:
def maybe_castable(dtype: DtypeObj) -> bool:
Copy link
Member

Choose a reason for hiding this comment

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

i think just np.dtype?

Copy link
Member Author

Choose a reason for hiding this comment

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

in light of #39104 (comment) , maybe it's worth mothballing this too until we have numpy types

Copy link
Contributor

Choose a reason for hiding this comment

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

kk let's revert this part

Copy link
Member

Choose a reason for hiding this comment

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

i dont understand why "just use np.dtype" isnt the right thing to do here

Copy link
Member Author

@MarcoGorelli MarcoGorelli Jan 31, 2021

Choose a reason for hiding this comment

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

I thought the objection was that it resolves to Any:

$ cat t.py 
import numpy as np

a: np.dtype
reveal_type(a)
$ mypy t.py 
t.py:4: note: Revealed type is 'Any'
  • is that OK?

Copy link
Member

Choose a reason for hiding this comment

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

wont that get fixed on numpy's end at some point? i mean, np.dtype is the correct type here

Copy link
Member

Choose a reason for hiding this comment

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

the problem (in general) is that we are adding a type that resolves to Any, so if there are mypy issues 'lurking' they will not be reported.

when we do have numpy types, we may then have more errors to resolve.

That train left the station long ago. so potentially having a few more errors is nbd.

this is a different scenario to #39104 (comment). That PR is focused on removing type ignores. In that case, the correct type is np.ufunc and not Callable, so again changing that is the right thing to do. just maybe not at the right time.

@jreback jreback added the Dtype Conversions Unexpected or buggy dtype conversions label Jan 21, 2021
@jreback jreback added this to the 1.3 milestone Feb 7, 2021
@jreback jreback added the Refactor Internal refactoring of code label Feb 7, 2021
@jreback jreback merged commit b15901e into pandas-dev:master Feb 7, 2021
@jreback
Copy link
Contributor

jreback commented Feb 7, 2021

thanks @MarcoGorelli

@MarcoGorelli MarcoGorelli deleted the ref-maybe-castable branch February 7, 2021 17:36
CyberQin pushed a commit to CyberQin/pandas that referenced this pull request Feb 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Dtype Conversions Unexpected or buggy dtype conversions Refactor Internal refactoring of code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants