operator.attrgetter() is neutered because it only accepts a single
attribute name, but it would really be much more useful if it accepted,
and followed a dotted attribute path, e.g.:

sorted(seq, key=operator.attrgetter('person.displayname'))

Of course attrgetter() would raise AttributeError if the entire path
could not be traversed.

How about a slight change to the proposed API, and make it a varargs
function?  E.g.

  operator.attrgetter('person', 'displayname')

This would avoid the need to parse the argument.

Unfortunately, that already has different, existing (and IMHO less
useful) semantics. :(

Fair enough. Fine with me then.

Mind if I take a look at the patch before it goes in?

I don't even mind if you *write* the patch :)

I actually haven't had time yet to hack it up, but I just reached my
threshold of tolerance so I had to at least report the bug.  I think
it's always a good idea to review patches before they go in anyway, so
if I work one up, I'll attach it here.

Hey Guido, can I borrow the keys to the time machine to get this into
Python 2.5.0? :)

What's wrong with

sorted(seq, key=lambda v:v.person.displayname)

I want to clarify that the proposed change would break:

operator.attrgetter(foo)(bar) == getattr(bar, foo)

Which is the documented intent of the operator module: "This module
exports a set of functions implemented in C corresponding to the
intrinsic operators of Python."

Unless, you are proposing getattr grow this functionality as well. IOW,
should PyObject_GetAttr* perform this recursion? If so, should
PyObject_HasAttr*, PyObject_DelAttr*, PyObject_SetAttr* do this as well?
At the moment, it is possible to have foo's (as in above) that contain
dots despite the inability to spell that in python's dereferencing
syntax. However, I don't know that anybody does that.

I'm not /personally/ concerned with the breakage because practicality
beats purity, and I don't want to use lambda because it's slower.  I've
never used operator.attrgetter() outside the specific use case of
sorted() and list.sort() so I'd like to make it able to be used in all
sorting-by-attribute-chasing use cases.

Other options: have sorted() and list.sort() grow another keyword
argument for the attribute-path; add another method called attrchaser()
in some module that adds the requested functionality.

I think Barry's proposal is fine.  If we need to update the docs, then
so be it.  His proposal adds useful functionality while keeping
readability and clarity.

FWIW, the getattr() explanation in the docs already needs to be expanded
to cover the multi-argument form of itemgetter.

The attached patch provides for the functionality requested. I've
updated the docstring of attrgetter related to this new feature and have
updated test_operator accordingly.

Mea culpa, the original patch I attached here has an obvious duplication
of code in test_operator.py. I've attached an updated patch to make life
easier on the commiter.

Attaching another patch that doesn't create a list of strings every time
the attrgetter is called. Also includes docs.

FWIW, Georg's patch works here.
Perhaps there should be a test for unicode attribute names since it is
special-cased in the patch.

Committed in r61027.