On 4/19/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote: > Perhaps when a code object is constructed it could include a reference > to the class where it was constructed (if any).
No, code objects shouldn't contain references to run-time artifacts (other than other code objects). Code objects must be marshallable. It's the function objects created from code objects that reference other run-time state (like globals, default values, and closure cells). > Then the class to use in > `super` would be obtained directly. I originally wanted to use im_class > rather than walk the MRO, but im_class didn't give the correct result, > and in any case I'd still need sys._getframe(). Perhaps the best way to implement super might be to create it as a "cell". Functions already have a mechanism to access cells that are passed in by the environment when the function objects is created. Perhaps 'super' could use a cell with a magic name to access the class. > This approach would of course not work properly if the same method was > then added to another class (a flaw shared by my recipe IIRC). One way > to deal with that would be to check that the class was actually in the > MRO of the current instance, and throw a TypeError if it's not. Methods that are shared between classes shouldn't reference super in either form. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
