ENH: add is_leap_year property for datetime-like #13739
Conversation
sinhrks
added
Enhancement
Datetime
sinhrks
changed the title
|
lgtm |
| @@ -332,6 +332,7 @@ API changes | |||
| - ``PeriodIndex.fillna`` with ``Period`` has different freq now coerces to ``object`` dtype (:issue:`13664`) | |||
| - More informative exceptions are passed through the csv parser. The exception type would now be the original exception type instead of ``CParserError``. (:issue:`13652`) | |||
| - ``astype()`` will now accept a dict of column name to data types mapping as the ``dtype`` argument. (:issue:`12086`) | |||
| - ``Timestamp``, ``Period``, ``DatetimeIndex``, ``PeriodIndex`` and ``.dt`` accessor has ``.is_leap_year`` property to return logical whether date belong to leap year. (:issue:`13727`) | |||
There was a problem hiding this comment.
has -> have
return logical -> check ? (sounds better IMO)
belong -> belongs
leap year -> a leap year
There was a problem hiding this comment.
Hmm, github is not really made for such linguistic review, would be much easier if I could just directly edit it .. :-)
|
add to docs here as well. note when looking at them again looks a tiny bit weird.....but makes sense |
| return is_leapyear(year) | ||
|
|
||
|
|
||
| cpdef isleapyear_arr(ndarray years): |
There was a problem hiding this comment.
Should we make this private? (_isleapyear_arr) Because if we regard functions here as internal, we actually don't need to deprecate isleapyear and could just remove it
|
@jorisvandenbossche @jreback Thx for kind reviews always:) Fixed points. |
Current coverage is 85.32% (diff: 100%)@@ master #13739 diff @@
==========================================
Files 141 141
Lines 50679 50686 +7
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
+ Hits 43240 43247 +7
Misses 7439 7439
Partials 0 0
|
| @@ -4822,8 +4833,23 @@ def dates_normalized(ndarray[int64_t] stamps, tz=None): | |||
| #---------------------------------------------------------------------- | |||
|
|
|||
| def isleapyear(int64_t year): | |||
There was a problem hiding this comment.
I don't think any reason to deprecate this; by-definition its internal if in tslib.pyx
There was a problem hiding this comment.
yeah i don't think users use it... simply removed.
sinhrks
force-pushed
the
is_leapyear
branch
3 times, most recently
from
208a6a7
to
f1a2098
Compare
|
lgtm. merge on pass. |
|
FYI depending on when you rebased, py3 may fail for this |
| @@ -609,7 +611,9 @@ Deprecations | |||
| - ``as_recarray`` has been deprecated in ``pd.read_csv()`` and will be removed in a future version (:issue:`13373`) | |||
| - top-level ``pd.ordered_merge()`` has been renamed to ``pd.merge_ordered()`` and the original name will be removed in a future version (:issue:`13358`) | |||
| - ``Timestamp.offset`` property (and named arg in the constructor), has been deprecated in favor of ``freq`` (:issue:`12160`) | |||
| - ``pivot_annual`` is deprecated. Use ``pivot_table`` as alternative, an example is :ref:`here <cookbook.pivot>` (:issue:`736`) | |||
| - ``pd.tseries.util.pivot_annual`` is deprecated. Use ``pivot_table`` as alternative, an example is :ref:`here <cookbook.pivot>` (:issue:`736`) | |||
| - ``pd.tseries.util.isleapyear`` and ``pd.tslib.isleapyear`` have been deprecated and will be removed in a subsequent release. Datetime-likes now have a ``.is_leap_year`` property. (:issue:`13727`) | |||
There was a problem hiding this comment.
The tslib.isleaypear is just deleted I think in the latest revision instead of deprecated, so we should remove it here
|
thanks @sinhrks |
git diff upstream/master | flake8 --difftslib.isleapyearalso, but i don't think it is public (deprecated also).pd.NaT.is_leap_yearresults inFalse, as I think users wantboolarray.