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

[Terry J. Reedy]

Terry J. Reedy <tjreedy at udel.edu> 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 make a keyword-only argument optional, and preferred over use of *args for making positional arguments optional.  Unless I am missing something, a function can special-case 'key is identity', to avoid overhead, just as well as it can special-case 'key is None'.  So rather than extend 'key=None', to me a kludge, I would rather replace it with 'key=identity'.  Both can be accepted during a deprecation period.

For instance, after adding identity,

def nsmallest(n, iterable, key=identity):
    ...
        if key is identity or key is None:  # key in (identity, None)
            result = min(it, default=sentinel)
    ...

Since no one need ever write key=None, explicit passing should be rare.  It seems to me that the main reason for the type declaration of key to include None is so that the def statement itself passes a consistency check with the None default.  Once that is changed, most people should be able to use a simple callable declaration.  I am considering this for python-ideas.

Since the weekly issues list came out just 10 hours ago, I will not close this yet, but I will if still open in couple of days and no coredev objections.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34149>
_______________________________________