The attached patch lets super() objects pass on
implicit __getitem__, __setitem__, __delitem__, __len__
and __hash__ calls. For example, to use len() with
super() objects, one must currently do something like

super(X, X()).__len__()

Likewise for __getitem__,

super(X, X()).__getitem__(item)

That's ugly.

This patch lets these be spelled as

len(super(X, X())) and super(X, X())[item], respectively.

The patch also includes documentation updates and tests
for the new functionality.

The patch was taken against r46582.

Logged In: YES 
user_id=1344176

The patch has been updated to reflect the current SVN state,
r47124.

Logged In: YES 
user_id=849994

Why only these methods? Why not __add__, __call__ etc.?
Implementing all of these methods is a pain and adds
considerable complexity to typeobject.c.

Frankly, I don't see an improvement since you normally only
call super.__getitem__ in __getitem__, and explicit is
better than implicit. Raymond, do you have a second opinion?

Logged In: YES 
user_id=1344176

I only added these particular methods because they were a)
the only ones I needed at the time, b) the only ones I
really had time to implement. I've now got a few more tuits
freed up, so I'd be happy to implement more of these methods.

As for "explicit is better than implicit", I don't see how
that applies here. The same case could be made for all of
Python's syntax-assisted method calls.

At one time, I had explored adding some of these methods and then dropped the idea because it left super() with an odd mish-mash of methods that are 1) forwarded 2) not-supported 3) handled directly by the super-object itself.

For instance, the repr() of a super-object and is handled directly by the super object.  Likewise, the members are part of the super-object and not forwarded.  

The current state of affairs can be explained (approximately) with the notion that named methods are forwarded but not any of the syntax-assisted implicit calls.  This patch clutters that state-of-affairs for a questionable benefit.

If you want to push for this, it should be discussed on python-dev so we can reach a concensus on what super-objects should be expected to do and not do.  Is it clear that so.__self__ and repr(so) act on the super object while a call like so[x] will traverse the mro?

Also, if something like this does go in, please optimize the calls to PyString_FromString() to be invoked no more than once per Python session (otherwise, syntax driven implicit calls may end-up being slower than named method access).

msg50389 asked for this to be discussed on python-dev.  I've searched the archives but didn't find anything obvious.  Did I simply miss it or was it never discussed?

I believe this is covered by the PEP3003 3.2 change moratorium.

Am rejecting this feature request because of the concerns mentioned in the post on 4/3.  The current requirement for explicit forwarding may be slightly inconvenient to type but it does add provide clarity that the method should be applied to the next-in-mro instead of the super object itself.

I appreciate the idea but think it would complicate an object that is already very difficult to understand and use correctly.