Skip to content

Conversation

@makbigc
Copy link
Contributor

@makbigc makbigc commented May 4, 2019

@codecov
Copy link

codecov bot commented May 4, 2019

Codecov Report

Merging #26280 into master will decrease coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@ Coverage Diff @@ ## master #26280 +/- ## ========================================== - Coverage 91.98% 91.98% -0.01%  ========================================== Files 175 175 Lines 52379 52379 ========================================== - Hits 48183 48179 -4  - Misses 4196 4200 +4
Flag Coverage Δ
#multiple 90.53% <100%> (ø) ⬆️
#single 40.73% <100%> (-0.15%) ⬇️
Impacted Files Coverage Δ
pandas/core/indexes/datetimelike.py 98.13% <100%> (ø) ⬆️
pandas/io/gbq.py 78.94% <0%> (-10.53%) ⬇️
pandas/core/frame.py 96.9% <0%> (-0.12%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f46ab96...1fd95eb. Read the comment docs.

@codecov
Copy link

codecov bot commented May 4, 2019

Codecov Report

Merging #26280 into master will increase coverage by 0.27%.
The diff coverage is 100%.

Impacted file tree graph

@@ Coverage Diff @@ ## master #26280 +/- ## ========================================== + Coverage 91.71% 91.99% +0.27%  ========================================== Files 178 180 +2 Lines 50755 50774 +19 ========================================== + Hits 46552 46708 +156  + Misses 4203 4066 -137
Flag Coverage Δ
#multiple 90.63% <100%> (+0.32%) ⬆️
#single 41.85% <100%> (+0.54%) ⬆️
Impacted Files Coverage Δ
pandas/core/arrays/base.py 99.43% <100%> (ø) ⬆️
pandas/core/indexes/datetimelike.py 98.14% <100%> (ø) ⬆️
pandas/core/algorithms.py 94.74% <100%> (ø) ⬆️
pandas/core/computation/check.py 85.71% <0%> (-6.6%) ⬇️
pandas/compat/__init__.py 92% <0%> (-1.55%) ⬇️
pandas/io/gbq.py 88.88% <0%> (-0.59%) ⬇️
pandas/tseries/offsets.py 96.36% <0%> (-0.33%) ⬇️
pandas/plotting/_matplotlib/hist.py 76.82% <0%> (-0.19%) ⬇️
pandas/core/frame.py 96.89% <0%> (-0.12%) ⬇️
pandas/plotting/_matplotlib/core.py 88.02% <0%> (-0.09%) ⬇️
... and 71 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5574a9f...b061ac1. Read the comment docs.

Copy link
Member

@WillAyd WillAyd left a comment

Choose a reason for hiding this comment

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

Thanks for the PR! Looks like there's an isort failure in CI

_isnan = cache_readonly(DatetimeLikeArrayMixin._isnan.fget)
hasnans = cache_readonly(DatetimeLikeArrayMixin._hasnans.fget)
_hasnans = hasnans # for index / array -agnostic code
_resolution = cache_readonly(DatetimeLikeArrayMixin._resolution.fget)
Copy link
Member

Choose a reason for hiding this comment

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

So it looks like these cache_readonly calls are what's tripping up mypy. @jbrockmendel might be able to offer some insight here

Copy link
Member

Choose a reason for hiding this comment

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

Is the problem with isort or mypy?

Copy link
Member

Choose a reason for hiding this comment

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

If its mypy then would it be that it wants something like # type: cache_readonly?

Copy link
Member

Choose a reason for hiding this comment

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

It's a mypy failure. Not actually with the cache_readonly as much as accessing the .fget attribute of the properties.

What's the intention of this code? Is passing fget from the property to cache_readonly faster than just accessing the property?

Copy link
Member

Choose a reason for hiding this comment

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

What's the intention of this code? Is passing fget from the property to cache_readonly faster than just accessing the property?

cache_readonly behaves like property, expecting to get a unary method as its argument. Does it even work if you don't make the .fget` explicit?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This failure is probably due to mypy. https://github.com/python/mypy/issues/6185

Deleting .fget run into other errors.

@WillAyd WillAyd added the Typing type annotations, mypy/pyright type checking label May 4, 2019
return self._data._data

@property
@property # type: ignore
Copy link
Contributor

Choose a reason for hiding this comment

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

why is this needed?

@makbigc makbigc force-pushed the typing-GH25882 branch 2 times, most recently from 8e67d73 to 7c56581 Compare May 8, 2019 03:58
@WillAyd
Copy link
Member

WillAyd commented May 14, 2019

Can you merge master?

@vaibhavhrt
Copy link
Contributor

@makbigc some of the errors in this file has been solved by #26404
You can go ahead and fix(or ignore) the remaining.

@WillAyd
Copy link
Member

WillAyd commented May 29, 2019

Can you merge master? Think this will be the last remaining module from the blacklist

@jreback
Copy link
Contributor

jreback commented May 30, 2019

can you merge master

@makbigc
Copy link
Contributor Author

makbigc commented May 30, 2019

mypy has the following error for the annotated value function:

pandas/core/indexes/datetimelike.py:139: error: "None" has no attribute "_data"

I add annotation # type: DatetimeArray to _data. But mypy still has the same error.

result._data = dtarr

Do you have any better way?

# ------------------------------------------------------------------------
# Abstract data attributes

@property
Copy link
Contributor

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
Contributor Author

Choose a reason for hiding this comment

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

mypy has the following error for the annotated value function:

pandas/core/indexes/datetimelike.py:139: error: "None" has no attribute "_data"

I add annotation # type: DatetimeArray to _data. But mypy still has the same error.

result._data = dtarr

I guess that mypy mixed up the instance attribute _data with the class attributes _data which is set None in the beginning of DatetimeIndexOpsMixin.

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

Sorry missed this ping. This could be a similar conversation to https://github.com/pandas-dev/pandas/pull/26518/files#r287573810

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 a better solution is to provide the appropriate type to _data. Can you create a DatetimeLikeArray in pandas._typing which should be something like DatetimeLikeArray = TypeVar('DatetimeLikeArray', DatetimeArray, PeriodArray, TimedeltaArray) and assign that type to _data in the class? I think that should resolve.

cc @jbrockmendel in case he has other insights on the types here

# ------------------------------------------------------------------------
# Abstract data attributes

@property
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 a better solution is to provide the appropriate type to _data. Can you create a DatetimeLikeArray in pandas._typing which should be something like DatetimeLikeArray = TypeVar('DatetimeLikeArray', DatetimeArray, PeriodArray, TimedeltaArray) and assign that type to _data in the class? I think that should resolve.

cc @jbrockmendel in case he has other insights on the types here

@WillAyd
Copy link
Member

WillAyd commented Jun 10, 2019

@makbigc can you merge master and address last comment? This should close out the reference issue (updated OP to reflect)

@makbigc
Copy link
Contributor Author

makbigc commented Jun 10, 2019

I can't figure out why DatetimeArray, PeriodArray and TimedeltaArray cannot be imported inside _typing.py

from pandas.core.arrays import DatetimeArray, PeriodArray, TimedeltaArray

ABCExtensionArray, ABCIndexClass, ABCSeries, ABCSparseSeries)

from pandas.core.arrays import DatetimeArray, PeriodArray, TimedeltaArray

Copy link
Contributor

Choose a reason for hiding this comment

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

don’t try to import these use a quoted version

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The following is the import error in the failed tests:
ImportError: cannot import name '_INT64_DTYPE'

The name of the module _typing.py is started with underscore. In PEP 8 (https://www.python.org/dev/peps/pep-0008/#descriptive-naming-styles ), it states

_single_leading_underscore: weak "internal use" indicator. E.g. from M import * does not import objects whose names start with an underscore.

Should we remove underscore from the name _typing? Or something else?

Copy link
Contributor

Choose a reason for hiding this comment

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

you can’t import these names as they would cause circular imports
and don’t need to just use ‘DatetimeArray’ and such

Copy link
Contributor Author

Choose a reason for hiding this comment

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

_INT64_DTYPE is just an alias, i.e., _INT64_DTYPE = np.dtype(np.int64). The import of numpy and the definition of _INT64_DTYPE are in the same file pandas/core/dtype/common.py.

I did a little experiment. Open a file called 'typing.py' (without underscore prefix) in the same directory as '_typing.py'. One can import DatetimeArray in typing.py.

Importing PeriodArray and TImedeltaArray also run into the same ImportError. Without them, one cannot define the mypy object TypeVar.
DatetimeLikeArray = TypeVar('DatetimeLikeArray', DatetimeArray, PeriodArray, TimedeltaArray).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@WillAyd Would you tell me your opinion? Should we change the filename of _typing.py?

@WillAyd
Copy link
Member

WillAyd commented Jun 18, 2019 via email

@makbigc
Copy link
Contributor Author

makbigc commented Jun 19, 2019

Yes, the problem is due to the circular import.
common -> _typing -> datetimelikey -> common
I can't resolve this circular import and datetimelike.py is the last exception in mypy.ini. So I close this PR for others picking it up.
Thanks all.

@makbigc makbigc closed this Jun 19, 2019
@WillAyd
Copy link
Member

WillAyd commented Jun 19, 2019

Doesn’t using the TYPE_CHECKING constant from the stdlib typing module in pandas._typing resolve the circular import?

I think this is really close!

@makbigc
Copy link
Contributor Author

makbigc commented Jun 20, 2019

@WillAyd Thanks for your reply. I have added the following in _typing.py

if TYPE_CHECKING: from pandas.core.arrays.datetimes import DatetimeArray from pandas.core.arrays.period import PeriodArray from pandas.core.arrays.timedeltas import TimedeltaArray DatetimeLikeArray = TypeVar('DatetimeLikeArray', DatetimeArray, PeriodArray, TimedeltaArray) 

and added the following to datetimelike.py

if TYPE_CHECKING: from pandas._typing import DatetimeLikeArray 

The circular import is solved. But mypy cannot find the DatetimeLikeArray!
pandas/core/indexes/datetimelike.py:67: error: Invalid type "pandas.DatetimeLikeArray"

@WillAyd WillAyd reopened this Jun 24, 2019
@jreback jreback added this to the 0.25.0 milestone Jun 25, 2019
@jreback
Copy link
Contributor

jreback commented Jun 25, 2019

lgtm. @WillAyd merge when ready.

@WillAyd WillAyd merged commit 606178a into pandas-dev:master Jun 25, 2019
@WillAyd
Copy link
Member

WillAyd commented Jun 25, 2019

Thanks @makbigc !

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

5 participants