[Python-Dev] Classes and Metaclasses in Smalltalk
Guido van Rossum
Wed, 02 May 2001 09:29:03 -0500
[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
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
--Guido van Rossum (home page: http://www.python.org/~guido/)