The motivation for this patch was to be able to chain together operator.itemgetter objects so that I could sort a list of items that have the form ((a,b), c) by the 'a' or 'b' part of the item.

Sorting by 'b' can be accomplished with:
l.sort(key=compose(itemgetter(1), itemgetter(0)))

compose(itemgetter(1), itemgetter(0)) is equivalent to

def c(v):
    return itemgetter(1)(itemgetter(0)(v))

The patch looks good, is complete (one nit, "Returns" should be "Return" in the doc) and the functionality belongs into functools.
What do you think, Martin?

Patch quality also looks good to me.

However, my main concerns would be whether or not the use case comes up often enough to justify inclusion in the standard library, and at what point it makes more sense to just use a lambda expression. For example, I think most people would find this easier to understand than the compose based version:

    l.sort(key=(lambda k: k[0][1]))

I guess the same (can use a lambda) could be said about the entire operators module, and the "entire" functools module.

I admit that in the specific example given, I would also find a lambda easier to read (in particular because it's more obvious that it is [0][1]).

catlee, what do you dislike about the lambda notation?

IMO, the lambda approach is more readable and more applicable to a variety of situations.

lambda k: k[0][1] is fine for this example.

I just thought that since operator.itemgetter existed that there should be a way to represent a series of __getitem__ calls in a similar way...and also that a way of composing functions would be generally useful to have in the stdlib.

FWIW, I think that the compose function would make it simpler to compose a set of functions that is determined at run-time.

It's also my experience that newbies have a hard time with lambda's :)

I'm rejecting the patch, because YAGNI. I agree that the quality of the patch is good; thanks for submitting it. I encourage you to post it to the Python Cookbook (if it's not there already); perhaps people may come back with an actual use case some day.

As for composing functions that are determined dynamically: this can be done already. Assume f and g are variables, you can do lambda arg:f(g(arg)). What you can't do is if you have a variably-sized list of functions to compose, but again, I think YAGNI (if that ever happens, writing a loop is easy enough).

Wrt newbies: I agree they have difficulties with lambda, but I think that is because they always have difficulties with first-class and higher-order functions. So they likely have the same problems with itemgetter and attrgetter (which are higher-order), and would have problems with compose. Even though I believe I can deal with callable objects just fine, I had problems understanding the example, because the order of the itemgetters is reversed to the "logical" order - although it is the standard order for composition in mathematics.

I concur with Martin's reasons for closing the patch.