Skip to content

TYP: update for numpy-1.21.0 #42200

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

Conversation

simonjayhawkins
Copy link
Member

No description provided.

@@ -142,7 +137,7 @@ def arrays_to_mgr(


def rec_array_to_mgr(
data: MaskedRecords | np.recarray | np.ndarray,
data: np.ma.MaskedArray | np.recarray | np.ndarray,
Copy link
Member

Choose a reason for hiding this comment

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

why this change?

Copy link
Member Author

Choose a reason for hiding this comment

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

There's a

    # fill if needed
    if isinstance(data, np.ma.MaskedArray):
        new_arrays = fill_masked_arrays(data, arr_columns)

in the body that implies that MaskedArray (which is a superclass?) is allowed?

Copy link
Member

Choose a reason for hiding this comment

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

In all tests that get here, we have isinstance(data, np.ma.mrecords.MaskedRecords). AFAICT the check is for MaskedArray bc MaskedRecords requires a separate import that we are avoiding at import-time

Copy link
Member Author

Choose a reason for hiding this comment

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

MaskedRecords, MaskedArray and recarray are all subclass of np.ndarray so the annotation here is redundant and should just be np.ndarray

Since MaskedArray is a subclass of np.ndarray, it is a valid type to pass to rec_array_to_mgr and mypy is correct that we pass off MaskedArray classes and subclasses to fill_masked_arrays

In all tests that get here

Isn't the point of mypy to catch the cases where we don't have tests?

but ok to leave for now. as we now have a cast and comment to highlight the issue

@@ -1784,11 +1790,9 @@ def na_accum_func(values: ArrayLike, accum_func, *, skipna: bool) -> ArrayLike:
# DatetimeArray/TimedeltaArray
# TODO: have this case go through a DTA method?
# For DatetimeTZDtype, view result as M8[ns]
values = cast("DatetimeArray | TimedeltaArray", values)
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 DatetimeArray (comment on L1790 should reflect this too); OK for follow-up.

Copy link
Member Author

Choose a reason for hiding this comment

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

actually it's probably best to remove the cast and keep the "fix later" ignore. A 3rd party EA subclass could satisfy values.dtype.kind in ["m", "M"] and would not have a _simple_new method as that's not a requirement of the EA api.

@jbrockmendel
Copy link
Member

The MaskedRecords change is the only one that looks questionable, everything else I think we can merge and cleanup in follow-ups.

@simonjayhawkins
Copy link
Member Author

The MaskedRecords change is the only one that looks questionable

sure. will look at that in detail tomorrow. feel free to push changes here in the meantime.

@lithomas1 lithomas1 added Typing type annotations, mypy/pyright type checking Compat pandas objects compatability with Numpy or Python functions labels Jun 23, 2021
@jreback
Copy link
Contributor

jreback commented Jun 23, 2021

may need to do a 1.2.6 with this unfortunately

@rhshadrach rhshadrach mentioned this pull request Jun 23, 2021
@jreback jreback added this to the 1.3 milestone Jun 23, 2021
@jreback
Copy link
Contributor

jreback commented Jun 23, 2021

@simonjayhawkins we need for 1.3 i assume.

@jbrockmendel
Copy link
Member

just pushed restoring the MaskedRecords annotation

@simonjayhawkins
Copy link
Member Author

@simonjayhawkins we need for 1.3 i assume.

not strictly, but best not to diverge the ci before we release

may need to do a 1.2.6 with this unfortunately

There are no behavioral code changes that indicate that there are issues with 1.2.5 and numpy 1.21

@simonjayhawkins
Copy link
Member Author

test_read_csv failing on Windows py38_np18 is not down to changes here

may need to do a 1.2.6 with this unfortunately

There are no behavioral code changes that indicate that there are issues with 1.2.5 and numpy 1.21

we had testing on 1.2.x for numpy-dev, but if we do get reports of issues with 1.2.5 and numpy 1.21 we may well want to do a 1.2.6 to fix (and then backport these changes to 1.2.x also, 1.2.x is on mypy 0.782 but probably not an issue)

@simonjayhawkins simonjayhawkins merged commit d113a3b into pandas-dev:master Jun 24, 2021
@simonjayhawkins simonjayhawkins deleted the update-for-numpy-1.21.0 branch June 24, 2021 09:55
meeseeksmachine pushed a commit to meeseeksmachine/pandas that referenced this pull request Jun 24, 2021
simonjayhawkins added a commit that referenced this pull request Jun 24, 2021
jbrockmendel added a commit to jbrockmendel/pandas that referenced this pull request Jun 24, 2021
JulianWgs pushed a commit to JulianWgs/pandas that referenced this pull request Jul 3, 2021
@@ -107,6 +108,8 @@
_int32_max = np.iinfo(np.int32).max
_int64_max = np.iinfo(np.int64).max

NumpyArrayT = TypeVar("NumpyArrayT", bound=np.ndarray)
Copy link
Member

Choose a reason for hiding this comment

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

why can't we just use np.ndarray?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Compat pandas objects compatability with Numpy or Python functions Typing type annotations, mypy/pyright type checking
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants