DEPR: rename offset alias ‘MS’ to ‘MB’

[natmokval]

As a follow up of renaming ‘M’ to ‘ME’ for MonthEnd (#52064) I suggest to rename strings denoting MonthBegin frequency from ‘MS’ to ‘MB’.

The reason: we have alias ‘ms’ for the class Milli and using ‘MB’ for MonthBegin will be more clear. It will help to create consistent naming for aliases.

[mathause]

Might be too late but it would make the life of downstream libraries easier if this was also included in 2.2 (if you do it). FYI @spencerkclark

[mathause]

Would that only be for month? Then it would be inconsistent with the other freq strings, which could be confusing ("MB" and "YS").

[natmokval]

Would that only be for month? Then it would be inconsistent with the other freq strings, which could be confusing ("MB" and "YS").

renaming the alias for MonthBegin to "MS" is just the beginning. The whole list of aliases to change:
"YE", "BYE", "QE", "BQE", "ME", "BME", "SME", "CBME"

[natmokval]

Might be too late but it would make the life of downstream libraries easier if this was also included in 2.2 (if you do it). FYI @spencerkclark

unfortunately there is not enough time to resolve this issue. The reason: after renaming "MS" to "MB" we need to rename other aliases denoting end of some time period.

[mathause]

unfortunately there is not enough time to resolve this issue. The reason: after renaming "MS" to "MB" we need to rename other aliases denoting end of some time period.

Inconvenient but understandable.

renaming the alias for MonthBegin to "MS" is just the beginning. The whole list of aliases to change: "YE", "BYE", "QE", "BQE", "ME", "BME", "SME", "CBME"

These are already implemented for pandas 2.2, right? And these are all consistent: all use "E" for end. But changing only "MS" to "MB", will leave us with "YS", "QS", "MB", ...., which I would find confusing.

But maybe I missed/ misunderstood something.

[natmokval]

unfortunately there is not enough time to resolve this issue. The reason: after renaming "MS" to "MB" we need to rename other aliases denoting end of some time period.

Inconvenient but understandable.

renaming the alias for MonthBegin to "MS" is just the beginning. The whole list of aliases to change: "YE", "BYE", "QE", "BQE", "ME", "BME", "SME", "CBME"

These are already implemented for pandas 2.2, right? And these are all consistent: all use "E" for end. But changing only "MS" to "MB", will leave us with "YS", "QS", "MB", ...., which I would find confusing.

sorry, it's my mistake. You are right, the renaming "Y", "Q", etc. to "YE", "QE", etc. is already implemented for pandas 2.2.

The list of aliases to change: “YS”, "BYS”, "QS”, "BQS”, "MS”, "BMS”, "SMS”, "CBMS”.

[aulemahal]

Hi all,
On one hand, I agree that it makes more sense to have "MB" as the class is named "MonthBegin". On the other, theses changes are very breaking for us (developpers and users of xclim). By the nature of the library, we have those strings "hardcoded" everywhere in the code, but even more so in user code.

I personally think that MS is fine as it is and that the change isn't worth the hassle. At the least, if all the breaking changes were in the same version (2.2), it would be much easier to work around!

I know our usage isn't representative of the vast majority of pandas' users, but I thought it was pertinent to raise that flag here. Thanks!

[jbrockmendel]

-0, there were some of these that were a real problem, but AFAICT those have all been handled

[MarcoGorelli]

thanks all for your comments!

there kind of still is a problem though. currently:

• pd.date_range('2000', periods=3, freq='YS') is valid (YearBegin)
• but pd.date_range('2000', periods=3, freq='ys') is also valid, and does the same thing (YearBegin)

however:

• pd.date_range('2000', periods=3, freq='MS') is valid (MonthBegin)
• but pd.date_range('2000', periods=3, freq='ms') is also valid, and means something completely different (millisecond)

One solution, as Natalia's suggesting, is to rename the *S ones to *B (all in one go - it's too late for 2.2, this would have to be for the 3.x cycle if agreed)
But another solution would be to disallow mixed-casing. So, 'YS' would mean YearBegin, and 'ys' would raise. Else, if people get used to being able to pass both uppercase and lowercase, then the 'MS' / 'ms' difference is going to bite them

[aulemahal]

If I may, from my perspective disallowing mixed-casing would be a preferable option. Offsets are described in the doc with a specific case, and same case is always used in examples (AFAIK). Disallowing mixed-case is still a "regression" as it removes a "feature", but at least it does not break the documented usage of the library.