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).