Logged In: YES 
user_id=80475

This one is tough.  

All of super's magic happens with descriptors upon attribute 
lookup.  The example above will work fine if the call were 
written as:  "super(D, self).__setitem__(name)".

However, when written as "super(D, self)[name]", ceval.c 
triggers a STORE_SUBSCR opcode which calls 
PyObject_SetItem which in turns looks directly at the super 
object's type table (and finding nothing).  Nowhere in this 
process is an attribute lookup called or a descriptor invoked.

The current implementation waits until attribute binding time 
to search the bases.  Hence, at the time the super object is 
created, it doesn't know enough information to fill out its 
table about which methods will be available.  Consequently, 
direct table probes will fail.

To make a general purpose fix would be a mess and involves 
changing the semantics of super to do its base search at the 
time the super object is created and to fillout its table with 
the appropriate methods.  Unfortunately, any dynamic 
changes to the methods in the base object would *not* get 
reflected at lookup.

There may be a reasonable special purpose fix.  Fill-out the 
entire superobject table with custom methods that trigger an 
attribute lookup.  For instance, fillout the sq_ass_item slot 
with a function that calls self.__setitem__ which will trigger 
the attribute search.  Even this approach has problems 
because the super object has no way of knowing in advance 
whether sq_ass_item or mp_ass_subscript is the appropriate 
method for the object being referred to (is it a mapping or a 
sequence?).

I recommend punting on this one and documenting that 
direct syntax manipulation of super objects is not defined 
and the super().__special_method__ format be used instead.
Perhaps, all of super's unfilled slots can be filled with a 
placeholder method that emits an explanatory error message.