I've attached a file which illustrates what I'm proposing to happen with the examples from the help.  Note that attrgetter (attr) is not affected, only attrgetter (*attrs) for more than one attribute.  The idea is that tuples resulting from attrgetter functions will retain the attribute names from the original object.  In some work I have done recently this would have been very handy with groupby.

I had some initial confusion because changing the Python attrgetter implementation didn't make any difference.  Once I realized I needed to turn off import of the C implementation, I figured the rest out fairly quickly.  Here is the diff:

diff --git a/Lib/operator.py b/Lib/operator.py
index 0e2e53e..9b2a8fa 100644
--- a/Lib/operator.py
+++ b/Lib/operator.py
@@ -247,8 +247,12 @@ class attrgetter:
         else:
             self._attrs = (attr,) + attrs
             getters = tuple(map(attrgetter, self._attrs))
+
+            from collections import namedtuple
+            nt = namedtuple ('attrgetter', self._attrs, rename=True)
+
             def func(obj):
-                return tuple(getter(obj) for getter in getters)
+                return nt._make (getter(obj) for getter in getters)
             self._call = func
 
     def __call__(self, obj):
@@ -409,7 +413,7 @@ def ixor(a, b):
 
 
 try:
-    from _operator import *
+    pass
 except ImportError:
     pass
 else:

There are some issues that still need to be addressed.  The biggest is that I've turned off the C implementation.  I assume that we'll need a C implementation the new version.  In addition to this:

1) I just call the namedtuple type "attrgetter".  I'm thinking something obtained by mashing together the field names or something similar might be more appropriate.  However, I would prefer not to repeat the logic within namedtuple that deals with field names that aren't identifiers.  So I'm wondering if maybe I should also modify namedtuple to allow None as the type name, in which case it would use an appropriate default type name based on the field names.

2) I import from collections inside the function.  It didn't seem to work at the top-level, I'm guessing because I'm in the library and collections isn't ready when operator is initialized.  This may be fine I just point it out as something on which I could use advice.

I'm hoping this provides enough detail for people to understand what I'm proposing and evaluate whether this is a desireable enhancement.  If so, I'll dig into the C implementation next, although I may need assistance with that.