| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
There was a problem hiding this comment.
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.
Sorry, something went wrong.
|
ISTM that adding an argument restriction to an already published function is a breaking change. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
Thanks Łukasz for sharing your thoughts!
Actually it's documented as positional-only, but only in 3.13+ branches: 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?). |
Sorry, something went wrong.
|
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 |
Sorry, something went wrong.
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? |
Sorry, something went wrong.
There was a problem hiding this comment.
Shouldn't we also add something in the "Deprecated" section of 3.14?
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM, except for missing comment on moved import.
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
There was a problem hiding this comment.
LGTM.
Sorry, something went wrong.
|
Thanks to all who participated! ❤️ |
Sorry, something went wrong.
…ntation of ``functools.reduce`` is called with `function` or `sequence` as a keyword args (python#121677) Python implementation of `functools` allows calling `reduce` with `function` or `sequence` as keyword args. This doesn't match behavior of our C accelerator and our documentation for `functools.reduce` states that `function`and `sequence` are positional-only arguments. Now calling a Python implementation of `functools.reduce` with `function` or `sequence` as keyword args would raise a `DeprecationWarning` and is planned to be prohibited in Python 3.16. Co-authored-by: Victor Stinner <vstinner@python.org> Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
| Back | FazBrowse Home | New Git URL |
Uh oh!
There was an error while loading. Please reload this page.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.