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

[Barry Warsaw]

-----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:
>    @requires_super
>    def __init__(self, super, **kwds):
>        super(**kwds)
>
>    # This method doesn't require super:
>    def some_method(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).

- -Barry

-----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-----