Consider this code snippet, simplified from a real application:

def display(self, *columns)
    getter = attrgetter(*columns)
    toprint = [[str(x) for x in getter(row)] for row in self._rows]

This works great...as long as there are two or more columns to print.
If there is only one column, it bombs because the getter returns a value
instead of a tuple.

This would not be a problem in and of itself, but there is no way to
tell attrgetter that I want a tuple even if there is only one value.

I believe it would be backward compatible to allow:

    attrgetter(['a'])
    itemgetter(['a', 'b'])

to return a tuple, since a list cannot be an attribute name.  The same
would apply to itemgetter, since a list cannot be a dictionary key.

Lists can't be dictionary keys, but they can appear in other mappings (e.g. an id-keyed mapping). So, while you could add this capability to attrgetter without breaking backwards compatibility, it's not possible for itemgetter.

It's unfortunate that the automatic scalar/tuple switchover design doesn't play well with start-args.  We have the same issue arising in a number of places (for example, min(*args) isn't happy when args is of length 1).

While inconvenient for variable length argument lists, I don't think the proposed solution is clean.  As it currently stands, the signature is reasonably simple, easy to explain, and doesn't depend on exact type checks (like %-formatting does with tuple/dict arguments).

Instead of contorting the signature for itemgetter(), it would be better if the use case were to be addressed with the existing language features:

>>> t = tuple('abcdefghi')
>>> for columns in ([], [2], [2,4], [2,4,6]):
	print(tuple(t[i] for i in columns))
	
()
('c',)
('c', 'e')
('c', 'e', 'g')

Given Nick's point about itemgetter, I agree this isn't worth doing.  I wouldn't want the signatures of attrgetter and itemgetter to no longer be parallel.

Min isn't a problem, by the way, since it accepts an iterator as a single argument.