In 2.6, the requirement for **kwds keyword argument expansion in calls (LangRef 5.3.4. Calls) is relaxed from "(subclass of) dictionary" (2.5) to "mapping".  The requirement in this context for 'mapping' is not specified. LRef3.2 merely says "The subscript notation a[k]  selects the item indexed by k from the mapping a;". Here, .keys seems to be needed in addition to .__getitem__. (.items alone does not make an object a mapping.)

In python-list thread "Which objects are expanded by double-star ** operator?", Peter Otten posted 2.6 results for

class A(object):
     def keys(self): return list("ab")
     def __getitem__(self, key):
         return 42
        
class B(dict):
     def keys(self): return list("ab")
     def __getitem__(self, key):
         return 42

def f(**kw):
     print(kw)

f(**A())
# {'a': 42, 'b': 42}

b = B(); print(b['a'], b['b']) # I added this
# 42, 42
f(**b)
# {}

I get same with 3.1. It appears .keys() is called in the first case, but not the second, possibly due to an internal optimization.

The different of outcome seems like a bug, though one could argue that the doc is so vague that it makes no promise to be broken.

This falls under the usual category of dict subclasses not having their methods called. Especially since the B dict doesn't actually contain anything.

Might that 'usual' fact be somehow documented? I am hard put to suggest anything since it is a fact I, like others, am not aware of. Is this a general rule for subclasses of builtins? or specific to dicts?

Somewhere, we should document the-facts-of-life for subclassing builtins.

1) For the most part, C code has the pattern
       if isinstance(obj, some_builtin_type):
           call the built_type's methods directly using slotted methods
       otherwise:
           use slower getattribute style calls

2) A subclasser of a dict needs to actually populate the dict with the values they want used.   The built-in dict class is "open for extension and closed for modification" -- the open/closed principle.  This is necessary or else a subclasser could easily break the built-in type's invariants and crash python.

3) For the most part, only something like subclassing UserDict gives you full control.