-
Notifications
You must be signed in to change notification settings - Fork 3
TRACKER: milestones #44
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
Comments
|
@mroeschke added 14. above, but i think should be straightforward, if you can work on this when you have a chance. |
@mroeschke, below please find some sample code that can be used to exercise pandas-dev#35690. Apologies for the inline-- couldn't get an attachment up on this tracker even applying some obvious trickery. Stick this into, say,
|
@RhysU I have a PR in the pandas repo that addresses the It passed your unit tests on my branch; I adapted some of the tests you had there in my PR |
@mroeschke, thank you. I pulled down pandas-dev#35848. I confirm that it passes the unit tests from above after I change my I then modified my
I observe that when the
This behavior goes to some of my uncertainty in pandas-dev#35690. My tests assert that a |
Looks like pandas currently allows indexing a tz-naive index with a tz-aware argument but with the implicit assumption to index the tz-naive index "as UTC"
So given this behavior, I would say is okay to have |
'Evening @mroeschke. I don't disagree with your assessment but I'll note that there seems to be little consistency in inferring UTC for a None tzinfo:
I see the same for Returning to my original tests, if I understand your point correctly then I expect that all
That is, all TZ_PAIRS should be acceptable and
where something down in the guts disagrees with the |
Thanks for bring up that example and testing out my patch. Taking a step back, I am not 100% sure where pandas lies today in regard to operations that involve an operation with a tz-naive and a tz-aware elements (indexing, comparisons, etc). Ideally it would be nice if there was consistency across all operations. I think there might be a push towards disallowing tz-naive and tz-aware objects from interacting, but that might need a larger discussion in pandas-dev#35690 or with the core team. What would be your opinion if in
|
@mroeschke, The timezones needing to match (in the sense that mixing tz-naive and tz-aware raises TypeError) in |
Sorry for the delay @RhysU. I think my PR to fix |
Thank you for following-up @mroeschke. On the PR I now see consistency in Concretely, with
In any follow-on work, please do check that any ValueErrors are consistent across the various data types. Appreciate all your effort here. Land away! |
In order in which we should tackle them:
halflife
(No Pandas issue yet).parallel=True
, usenumba.prange
) when doingapply
groupby.apply
(Note: udf must be a reduction op until parallel list comprehension corruption numba/numba#4579 is solved)rolling.apply
groupby.rolling.apply
groupby.agg
groupby.transform
df._window(indexer, aggregator, kernel)
anddf.groupby._window(indexer, aggregator, kernel)
..ewm(...).apply
(No pandas issue yet).groupby(..).expanding()
via indexers: PERF: ExpandingGroupby pandas-dev/pandas#37064.groupby(..).ewma()
via indexers (ENH: Support groupby.ewm operations pandas-dev/pandas#37878)explore for say.rolling(...).mean/sum/max/min
if doing this in numba is faster / can / should we call the cython function. (prob not worth it)The text was updated successfully, but these errors were encountered: