BUG: Fix freq setter for DatetimeIndex/TimedeltaIndex and deprecate for PeriodIndex by jschendel · Pull Request #20772 · pandas-dev/pandas (original) (raw)
Is there a compelling use-case to actually set freq (whether inplace or return a new object) on a DTI/TDI?
I made this PR after noticing a few SO questions that worked around the buggy setting behavior. That doesn't necessarily there's actually a valid use case for it, as there may be more direct workarounds for the issues people are having, but at the very least people are trying to use it.
I think one of the issues is that people generally default to using pd.to_datetime
for parsing, which as far as I can tell does not have the ability to set a frequency on creation, and so they then want to set a frequency after creation. This might be more of an argument for a freq
parameter in pd.to_datetime
though. There also isn't much documentation for the freq='infer'
option of the DTI constructor, so I also see people wanting to set the inferred frequency after creation, without actually knowing what that frequency is (again, more of a documentation issue).
I could also imagine a use case where one has messy data which needs to be cleaned first, prior to actually setting the freq
. So a workflow like parse -> clean -> set frequency. Some cleaning operations may take care of the setting the freq
, but there are cases where multiple frequencies are possible, so the correct one may not be set, or a custom frequency may be desired, or maybe no frequency is desired and a user wants to remove by setting None
.
Whether .asfreq happens to do work on a PI, and doesn't on a TDI/DTI is not a compelling argument.
To add another data point, Series.asfreq
and DataFrame.asfreq
will also do work on an underlying DTI (doesn't appear to work for TDI).
Not particularly invested in being for/against reusing the asfreq
name though, as there are downsides to both without a clear winner in my mind (potential for confusion with reuse vs. API bloat for new method).