[Python-Dev] Classes and Metaclasses in Smalltalk

[Guido van Rossum]

[Greg Ward, welcome back!]
> I was just doing some gedanken with various ways to spell "super", and I
> think my favourite is the same as Java's (as I remember it):
> 
> class MyClass (BaseClass):
>     def foo (self, arg1, arg2):
>          super.foo(arg1, arg2)

I'm sure that's everybody's favorite way to spell it!  It's mine too. :-)

> Since I don't know much about Python's guts, I can't say how
> implementable this is, but I like the spelling.  The semantics would be
> something like this (with adjustments to the reality of Python's guts):
> 
>   * 'super' is a magic object that only makes sense inside a 'def'
>     inside a 'class' (at least for now; perhaps it could be generalized
>     to work at class scope as well as method scope, but let's keep
>     it simple)

Yes, that's about the only way it can be made to work.  The compiler
will have to (1) detect that 'super' is a free variable, and (2) make
it a local and initialize it with the proper magic.  Or, to relieve
the burden from the symbol table, we could make super a keyword, at
the cost of breaking existing code.

I don't think super is needed outside methods.

>   * super's notional __getattr__() does something like this:
>     - peek at the calling stack frame and fetch the calling function
>       (MyClass.foo) and the first argument to that function (self)
>     - [is this possible?] ensure that calling_function is a bound
>       method, and that it's bound to the self object we just plucked
>       from the stack; raise a "misuse of super object" exception if not

I don't think you can make that test, but making it a 'magic local'
as I suggested above would avoid the problem.

>     - walk the superclass tree starting at self.__class__.__bases__
>       (ie. skip self's class), looking for an object with the name
>       passed to this __getattr__() call -- 'foo'
>     - when found, return it
>     - if not found, raise AttributeError

Yup, that's the easy part. :-)

> The ability to peek at the calling stack frame is essential to this
> scheme, in order to fetch the "current object" (self) without needing to
> have it explicitly passed.  Is this as bothersome from C as it is from
> Python?

No, in C it's easy.  The problem is that there is no information in
the frame that tells you where the currently executing function was
defined -- all you have is the code object, which is
context-independent.

--Guido van Rossum (home page: http://www.python.org/~guido/)