[Python-Dev] Problems with the new super() (original) (raw)

Barry Warsaw barry at python.org
Fri May 2 01:45:46 CEST 2008

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On May 1, 2008, at 6:33 PM, Andrew McNabb wrote:

On Thu, May 01, 2008 at 12:55:22PM -0700, Guido van Rossum wrote:

I'm not proud of this, but I don't see a way around it. The alternative would be to make it a keyword, which seemed excessive (plus, it would be odd if super() were a keyword when self is not). There were long discussions about various possible ways to implement something like this, and they all had their downsides. (The PEP still isn't fixed to describe the status quo.) I remember some brainstorms about treating more like self. I'm not sure if these were thought through all the way, but I remember seeing something like: class MyClass(Super1, Super2): # This method requires super: @requiressuper def init(self, super, **kwds): super(**kwds) # This method doesn't require super: def somemethod(self): pass I'm sure there are drawbacks, but it fits in my head. Using super in Python 2.0 is verbose but simple. However, I'm a little scared of super in Python 3.0. I guess I'm probably just a wimp.

It certainly makes me uncomfortable too. I think of all the
alternatives in PEP 3135, I'd probably prefer self.super.foo(),
except that I'd call it self.super.foo().

Although I don't mind reserving a non-underscore-adorned name for
Python 3.0, I could see adopting self.super and using
super(self).foo() as a shortcut. To me, that addresses the main
rationale of the PEP without the magic (i.e. no need to repeat the
class).

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBSBpWLHEjvBPtnXfVAQJmOAP+NW1tj67Ls+m6PCbF9wYpPRQhT2RJ1210 0QdYxyYz8akY5+I1QJTp3BN5erDLw1sAWGcKVP2phw7Rvb3pXf8FGh/Yg8du7KAg ZAm96xdaNLPiATVDaZZHuoWZ3+S6zUbmx6QtpjU//EAOXhwQCoTdhDme9QyPDI/2 kA+oldSXr+M= =bBRP -----END PGP SIGNATURE-----

More information about the Python-Dev mailing list