[Python-Dev] New Super PEP

[Calvin Spealman]

Comments welcome, of course. Bare with my first attempt at crafting a PEP.

PEP: XXX
Title: Super As A Keyword
Version: $Revision$
Last-Modified: $Date$
Author: Calvin Spealman <ironfroggy at gmail.com>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 30-Apr-2007
Python-Version: 2.6
Post-History:


Abstract
========

The PEP defines the proposal to enhance the super builtin to work implicitly
upon the class within which it is used and upon the instance the current
function was called on. The premise of the new super usage suggested is as
follows:

    super.foo(1, 2)

to replace the old:

    super(Foo, self).foo(1, 2)


Rationale
=========

The current usage of super requires an explicit passing of both the class and
instance it must operate from, requiring a breaking of the DRY (Don't Repeat
Yourself) rule. This hinders any change in class name, and is often considered
a wart by many.


Specification
=============

Replacing the old usage of super, calls to the next class in the MRO (method
resolution order) will be made without an explicit super object creation,
by simply accessing an attribute on the super type directly, which will
automatically apply the class and instance to perform the proper lookup. The
following example demonstrates the use of this.

    ::

        class A(object):
            def f(self):
                return 'A'

        class B(A):
            def f(self):
                return 'B' + super.f()

        class C(A):
            def f(self):
                return 'C' + super.f()

        class D(B, C):
            def f(self):
                return 'D' + super.f()

        assert D().f() == 'DBCA'

The proposal adds a dynamic attribute lookup to the super type, which will
automatically determine the proper class and instance parameters. Each super
attribute lookup identifies these parameters and performs the super lookup on
the instance, as the current super implementation does with the explicit
invokation of a super object upon a class and instance.

The enhancements to the super type will define a new __getattr__ classmethod
of the super type, which must look backwards to the previous frame and locate
the instance object. This can be naively determined by located the local named
by the first argument to the function. Using super outside of a function where
this is a valid lookup for the instance can be considered undocumented in its
behavior.

Every class will gain a new special attribute, __super__, which is a super
object instansiated only with the class it is an attribute of. In this
capacity, the new super also acts as its own descriptor, create an instance-
specific super upon lookup.

Much of this was discussed in the thread of the python-dev list, "Fixing super
anyone?" [1]_.

Open Issues
-----------

__call__ methods
''''''''''''''''

Backward compatability of the super type API raises some issues. Names, the
lookup of the __call__ of the super type itself, which means a conflict with
doing an actual super lookup of the __call__ attribute. Namely, the following
is ambiguous in the current proposal:

    ::

        super.__call__(arg)

Which means the backward compatible API, which involves instansiating the super
type, will either not be possible, because it will actually do a super lookup
on the __call__ attribute, or there will be no way to perform a super lookup on
the __call__ attribute. Both seem unacceptable, so any suggestions are welcome.

super type's new getattr
''''''''''''''''''''''''

To give the behavior needed, the super type either needs a way to do dynamic
lookup of attributes on the super type object itself or define a metaclass for
the builtin type. This author is unsure which, if either, is possible with C-
defined types.

When should we create __super__ attributes?
'''''''''''''''''''''''''''''''''''''''''''

They either need to be created on class creation or on __super__ attribute
lookup. For the second, they could be cached, of course, which seems like it
may be the best idea, if implicit creation of a super object for every class is
considered too much overhead.


References
==========

.. [1] Fixing super anyone?
   (http://mail.python.org/pipermail/python-3000/2007-April/006667.html)


Copyright
=========

This document has been placed in the public domain.



..
   Local Variables:
   mode: indented-text
   indent-tabs-mode: nil
   sentence-end-double-space: t
   fill-column: 70
   coding: utf-8
   End:


-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://ironfroggy-code.blogspot.com/