Title: Improve super() objects support for implicit method calls
Type: enhancement Stage: patch review
Components: Interpreter Core Versions: Python 3.3
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: BreamoreBoy, collinwinter, georg.brandl, rhettinger, terry.reedy
Priority: normal Keywords:

Created on 2006-05-31 17:31 by collinwinter, last changed 2011-02-16 07:32 by orsenthil. This issue is now closed.

File name Uploaded Description Edit
better_super.patch collinwinter, 2006-06-27 12:22 Improve super() objects, against r47124
Messages (8)
msg50385 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2006-05-31 17:31
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.
msg50386 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2006-06-27 12:22
Logged In: YES 

The patch has been updated to reflect the current SVN state,
msg50387 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2006-07-17 13:05
Logged In: YES 

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?
msg50388 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2006-07-17 13:13
Logged In: YES 

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.
msg50389 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2007-04-03 02:33
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).
msg110449 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-07-16 14:58
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?
msg113455 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2010-08-09 18:57
I believe this is covered by the PEP3003 3.2 change moratorium.
msg113613 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-08-11 19:08
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.
Date User Action Args
2011-02-16 07:32:57orsenthilsetkeywords: - after moratorium
nosy: georg.brandl, collinwinter, rhettinger, terry.reedy, BreamoreBoy
2010-08-11 19:08:48rhettingersetstatus: open -> closed
assignee: collinwinter -> rhettinger
resolution: rejected
messages: + msg113613
2010-08-09 18:57:52terry.reedysetversions: + Python 3.3, - Python 3.2
nosy: + terry.reedy

messages: + msg113455

keywords: + after moratorium, - patch
2010-07-16 14:58:00BreamoreBoysetnosy: + BreamoreBoy

messages: + msg110449
versions: + Python 3.2, - Python 3.1, Python 2.7
2009-03-21 03:38:49ajaksu2setstage: patch review
type: enhancement
versions: + Python 3.1, Python 2.7, - Python 2.6
2006-05-31 17:31:43collinwintercreate