gh-121676: Raise a DeprecationWarning if the Python implementation of functools.reduce is called with a keyword args

[Eclips4]

• Issue: Python implementation of functools.reduce accepts keyword arguments, while the C implementation does not #121676

[vstinner]

LGTM.

In general, the C implementation is always used so functools.reduce() doesn't accept keyword arguments. This change fix an inconsistency when the C extension (_functools) cannot be loaded.

[rhettinger]

ISTM that adding an argument restriction to an already published function is a breaking change.

[ambv]

I see how @Eclips4 would conclude that the likelihood of users running the Python version of functools.reduce is low. However, I have to agree with Nikita and Raymond here. It is unknowable whether users had or had not depended on keyword arguments here, especially after the function existing for so long. A lot of code isn't open.

In general, it might be tempting to treat a case like this one as a special case and relax our usual standards, but I believe it's not worth doing: we're not fixing a crippling problem, and we're not unblocking users to perform a legitimate operation. This change is a cleanup to improve consistency, it's not urgent.

Moreover, the function isn't actually documented as positional-only, so we cannot claim that the current behavior of the pure Python implementation was against stated intent.

Therefore, the responsible thing to do here would be to deprecate keyword argument use (through an awkward *args, **kwargs wrapper that would discover keyword usage and warn). Best case scenario, we might ask Thomas if he'd be okay with this new deprecation would be okay for 3.13 still, even though it's officially too late for that. But as Kirill says, the blast radius is limited as the function is shadowed by the C implementation for the vast majority of users.

[Eclips4]

Thanks Łukasz for sharing your thoughts!

Moreover, the function isn't actually documented as positional-only, so we cannot claim that the current behavior of the pure Python implementation was against stated intent.

Actually it's documented as positional-only, but only in 3.13+ branches:
https://docs.python.org/3.13/library/functools.html#functools.reduce

I absolutely agree with you that if we can deprecate it for 3.13, that would be fine. If not, that would also be fine (should we then revert the change to the docs mentioned above?).
cc @Yhg1s

[Yhg1s]

No, I don't think this should be done in 3.13. The potential impact is low, but so is the benefit. It's fine to leave it documented as positional-only, but changes in behaviour (if warranted at all, and following the normal deprecation process) should go into 3.14 instead

PR was rewritten since I approved it

[vstinner]

What's the status of this PR? I'm now confused :-(

[Eclips4]

What's the status of this PR? I'm now confused :-(

I'm waiting for PR #125917 to be merged, so the initial argument would be pos-and-keyword. Therefore, I will change this PR to raise a DeprecationWarning if the Python version of functools.reduce is called with a function or sequence as a keyword argument. What do you think?

[skirpichev]

Now #125917 is merged. I think that @vstinner review should be dismissed as this pr reworked to allow initial kwarg.

[picnixz]

Shouldn't we also add something in the "Deprecated" section of 3.14?

[skirpichev]

LGTM, except for missing comment on moved import.

[picnixz]

I'm suggesting renaming _warn_kwargs to something more explicit for anyone stumbling upon the code. I'm also suggesting deleting the decorator from the module's global names.

I'm not sure if all my suggestions will pass the CI so just double-check before hitting the "commit suggestion" button if you want.

[picnixz]

LGTM.

[Eclips4]

Thanks to all who participated! ❤️