Indeed it is important to not only consider the potential use cases for such a placeholder function, but to consider the cases that go beyond of what a lambda can do. A lambda is always a good option if it is used as a "single-serving" function, i.e. one that is only relevant locally where it is coded (and not stored somewhere). If on the other hand the function is to be reused or users are expected to interact with it, more clarity is needed (e.g. a descriptive `repr`). Of course in such cases a developer could always go with a proper function definition and even supply it with a doc string; it's just that for simple cases this feels a bit heavy. In the end it would provide a concise solution for cases where (a) partializing via keyword is not possible (positional-only parameters now being official might give rise to new use cases as well) and (b) the function is not "single-service", i.e. it is retained in some way (where PEP 8 says "do not assign a lambda"). As an example say there's a 2D array (semantics like numpy) and we want to convert a flat index to 2D-index (numpy contains such functionality but let's say we're doing something more lightweight):
a = array([[1, 2, 3], [4, 5, 6], [7, 8, 9]]) convert_flat_index = placeholder(divmod, ..., a.shape[1]) assert a[convert_flat_index(4)] == 5 assert a[convert_flat_index(8)] == 9
The other option would be a full-fledged function definition (which seems a bit heavy):
def generate_index_converter(n): def convert_flat_index(x): return divmod(x, n) return convert_flat_index