[issue34149] Behavior of the min/max with key=None

Raymond Hettinger added the comment: Alexander, thanks for the suggestion and patch. -- components: +Library (Lib) resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue34149] Behavior of the min/max with key=None

Raymond Hettinger added the comment: New changeset e22072fb11246f125aa9ff7629c832b9e2407ef0 by Raymond Hettinger (Alexander Marshalov) in branch 'master': bpo-34149: Behavior of the min/max with key=None (GH-8328) https://github.com/python/cpython/commit/e22072fb11246f125aa9ff7629c832b9e2407e

[issue34149] Behavior of the min/max with key=None

Raymond Hettinger added the comment: Repeating my comment on the Github PR, "I'm persuaded by your idea that min(), max(), nsmallest(), nlargest(), sorted(), and itertools.groupby() should ideally have the same API for key functions. Syncing of those APIs would be a minor improvement. As Ser

[issue34149] Behavior of the min/max with key=None

Terry J. Reedy added the comment: FWIW, the nsmallest/largest key param was added Dec 2, 2004, before keyword-only parameters. https://github.com/python/cpython/commit/4901a1f267e9d632f85054ce8b21ff23bff305e1 -- ___ Python tracker

[issue34149] Behavior of the min/max with key=None

Terry J. Reedy added the comment: In 2.x, map(None, 'abc', 'zyz') == [('a', 'z'), ('b', 'y'), ('c', 'z')], but with the addition of zip, so that zip('abc', 'xyz') has the same result, we deprecated that use of None to mean identity function. For python-coded functions, a default is needed to

[issue34149] Behavior of the min/max with key=None

Raymond Hettinger added the comment: Serhiy, feel free to reject this PR. -- ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue34149] Behavior of the min/max with key=None

Serhiy Storchaka added the comment: Accepting None makes the typing model more complex. Instead of just a callable functions accept callable-or-none. It terms of annotations, it is Union[Callable[[Any], Any], None] instead of just Callable[[Any], Any]. -- ___

[issue34149] Behavior of the min/max with key=None

Raymond Hettinger added the comment: > Whouldn't be better to add operator.identity and use it as the default value > instead of None? No, that would incur overhead that currently isn't present. -- ___ Python tracker

[issue34149] Behavior of the min/max with key=None

Serhiy Storchaka added the comment: Whouldn't be better to add operator.identity and use it as the default value instead of None? -- ___ Python tracker ___ __

[issue34149] Behavior of the min/max with key=None

Raymond Hettinger added the comment: +0 Probably users will never care about this but I don't see a downside beyond the small API churn. -- ___ Python tracker ___ ___

[issue34149] Behavior of the min/max with key=None

Serhiy Storchaka added the comment: Accepting None has a drawback. It can hide a bug when the key function unexpectedly becomes None. -- nosy: +bethard, rhettinger, serhiy.storchaka ___ Python tracker _

[issue34149] Behavior of the min/max with key=None

Change by Alexander Marshalov <_...@marshalov.org>: -- keywords: +patch pull_requests: +7864 stage: -> patch review ___ Python tracker ___

[issue34149] Behavior of the min/max with key=None

New submission from Alexander Marshalov <_...@marshalov.org>: I was faced with the fact that the behavior of the functions "min"/"max" and "sorted" is a little different. For example, this code works fine: >>> sorted([3, 2, 1], key=None) [1, 2, 3] But the same example for "min" and "