BUG: GH-15354 ENH breaks documentation example with non-backward-compatible signature change

[tobiscode]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

# from https://pandas.pydata.org/docs/user_guide/window.html#custom-window-rolling

import numpy as np
import pandas as pd

use_expanding = [True, False, True, False, True]
df = pd.DataFrame({"values": range(5)})
from pandas.api.indexers import BaseIndexer

class CustomIndexer(BaseIndexer):
    def get_window_bounds(self, num_values, min_periods, center, closed):
        start = np.empty(num_values, dtype=np.int64)
        end = np.empty(num_values, dtype=np.int64)
        for i in range(num_values):
            if self.use_expanding[i]:
                start[i] = 0
                end[i] = i + 1
            else:
                start[i] = i
                end[i] = i + self.window_size
        return start, end

indexer = CustomIndexer(window_size=1, use_expanding=use_expanding)

df.rolling(indexer).sum()

# Traceback (most recent call last):
#   File "<stdin>", line 1, in <module>
#   File "/home/USER/apps/miniconda3/envs/test/lib/python3.10/site-packages/pandas/core/generic.py", line 11999, in rolling
#     return Rolling(
#   File "/home/USER/apps/miniconda3/envs/test/lib/python3.10/site-packages/pandas/core/window/rolling.py", line 165, in __init__
#     self._validate()
#   File "/home/USER/apps/miniconda3/envs/test/lib/python3.10/site-packages/pandas/core/window/rolling.py", line 1822, in _validate
#     super()._validate()
#   File "/home/USER/apps/miniconda3/envs/test/lib/python3.10/site-packages/pandas/core/window/rolling.py", line 227, in _validate
#     raise ValueError(
# ValueError: CustomIndexer does not implement the correct signature for get_window_bounds

Issue Description

From what I can tell, the signature check carried out in https://github.com/pandas-dev/pandas/blob/v1.5.2/pandas/core/window/rolling.py#L217 is too strict for the check to pass. Since the old signature is a strict subset of the new signature, a check that only requires the first 5 parameters to be the same would be enough. Sadly, this breaking change was not discovered during the rollout/checks #45765 and then therefore not documented in the changelog as a breaking change.

Since I'm the developer of a package that relies on this custom indexing behavior, I wanted to ask whether this is an issue worth fixing (i.e., making >=1.5.x backwards-compatible signature-wise) or whether it should just be noted in the documentation and changelog that this is non-compatible upgrade behavior. (Since that will then inform what I want to do with my package, whether to push an update for the signature to match pandas 1.5 and set a package requirement pandas>=1.5, or just wait.)

Cheers

Expected Behavior

df.rolling(indexer).sum()
#    values
# 0     0.0
# 1     1.0
# 2     3.0
# 3     3.0
# 4    10.0

Installed Versions

INSTALLED VERSIONS

commit : 8dab54d
python : 3.10.8.final.0
python-bits : 64
OS : Linux
OS-release : 4.18.0-348.2.1.el8_5.x86_64
Version : #1 SMP Mon Nov 8 13:30:15 EST 2021
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 1.5.2
numpy : 1.23.5
pytz : 2022.7
dateutil : 2.8.2
setuptools : 65.5.0
pip : 22.3.1
Cython : None
pytest : None
hypothesis : None
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : None
IPython : None
pandas_datareader: None
bs4 : None
bottleneck : 1.3.5
brotli : None
fastparquet : None
fsspec : None
gcsfs : None
matplotlib : None
numba : None
numexpr : 2.8.4
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : None
pyreadstat : None
pyxlsb : None
s3fs : None
scipy : None
snappy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlwt : None
zstandard : None
tzdata : None

[tobiscode]

Just wanted to bump this issue so that it's not getting forgotten, since it still represent backwards-incompatible behavior and breaks a documentation example.

[Aloqeely]

Thanks for the report! Sorry for the very late response but I suppose this should've been deprecated before being changed.

It's been long since this issue so I assume everything is good right now, going to close but feel free to reopen if the issue still persists.