python
gh-121676: Raise a ``DeprecationWarning`` if the Python implementation of ``functools.reduce`` is called with a keyword args
ISTM that adding an argument restriction to an already published function is a breaking change.
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.
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
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
I don't find any results in the top 8k PyPI projects (searching for "functools.reduce.*(function=|sequence=)" or " reduce\(.*(function=|sequence=)").
FYI pypy accepts keyword arguments:
Is there a good reason not to go the other way, and allow keyword arguments for the C implementation?
Is there a good reason not to go the other way, and allow keyword arguments for the C implementation?
In principle, this adds some overhead. But from my tests on cmath module (see this) - it's something like 2-3%. Perhaps, for reduce this will be even less important for most workloads.
I don't find any results in the top 8k PyPI projects (searching for
"functools.reduce.*(function=|sequence=)"or" reduce\(.*(function=|sequence=)").FYI pypy accepts keyword arguments:
Is there a good reason not to go the other way, and allow keyword arguments for the C implementation?
PyPy accepts keyword arguments because it reuses the CPython pure python implementation of functools, so this is not done purposely by the PyPy team. I guess there is no reason not to extend the reduce signature to support keyword arguments.
PyPy accepts keyword arguments because it reuses the CPython pure python implementation of functools, so this is not done purposely by the PyPy team. I guess there is no reason not to extend the reduce signature to support keyword arguments.
That maybe true in this specific case, but more generally, PyPy's RPython-implemented functions have keyword arguments for everything by default. We need to do extra work to not expose them, and in general we would prefer everything to have keyword arguments.
I'm in favor of making keyword args supported for _functools.reduce.
If others don't complain about it, I'll rework this PR!
I missed this. Is there an agreement on this? I am not sure what to do about my PR.
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?
Now https://github.com/python/cpython/pull/125917 is merged. I think that @vstinner review should be dismissed as this pr reworked to allow initial kwarg.