-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
WIP: implement period_helper in cython #19498
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
Conversation
Codecov Report
@@ Coverage Diff @@
## master #19498 +/- ##
==========================================
- Coverage 91.67% 91.62% -0.06%
==========================================
Files 148 150 +2
Lines 48553 48681 +128
==========================================
+ Hits 44513 44604 +91
- Misses 4040 4077 +37
Continue to review full report at Codecov.
|
# Conventions | ||
|
||
@cython.cdivision | ||
cdef inline int get_freq_group_index(int freq) nogil: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe lets make a pandas._libs/period/....
subdir here rather than trying to jam into tslibs (and move period as well)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
a precursor PR to move period would make this easier
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is definitely a mess; unfortunately my attempts to port it piece-meal segfaulted all over the place.
But I think this does belong in tslibs. A ton of the code moved from period_helper is redundant with np_datetime, ccalendar (if we get rid of the unused JULIAN_CALENDAR branches), and frequencies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shoyer IIRC you mentioned xarray users needing non-gregorian calendar implementations of... something. Am I remembering that right? If so, is there anything useful in the JULIAN_CALENDAR code for period_helper that should be retained instead of ripped out?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, still make it a subdir, maybe pandas/_lib/tslibs/period
then
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the Julian calendar part is worth keeping around for xarray users.
Climate scientists use non-Gregorian calendars (e.g., a "365 day calendar") to simplify keeping track of seasons in climate models. But I don't think the Julian calendar is particularly interesting here.
Closing in favor of #19534 and follow-ups. |
Tests pass locally, haven't run asv yet. Lots of cleanup to do; function names are retained, use camelCase. A bunch of functions overlap with ccalendar (even more so if we remove the unused non-GREGORIAN_CALENDAR case)
git diff upstream/master -u -- "*.py" | flake8 --diff