[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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4