On 5/31/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 07:48 PM 5/31/2007 +0800, Guido van Rossum wrote: > >I've updated the patch; the latest version now contains the grammar > >and compiler changes needed to make super a keyword and to > >automatically add a required parameter 'super' when super is used. > >This requires the latest p3yk branch (r55692 or higher). > > > >Comments anyone? What do people think of the change of semantics for > >the im_class field of bound (and unbound) methods? > > Please correct me if I'm wrong, but just looking at the patch it > seems to me that the descriptor protocol is being changed as well -- > i.e., the 'type' argument is now the found-in-type in the case of an > instance __get__ as well as class __get__. > > It would seem to me that this change would break classmethods both on > the instance and class level, since the 'cls' argument is supposed to > be the derived class, not the class where the method was > defined. There also don't seem to be any tests for the use of super > in classmethods.
I've not gotten a new patch out based on a completely different approach. (I'm afraid I didn't quite get your suggestion so this is original work.) It creates a cell named __class__ which is shared between all methods defined in a particular class, and initialized to the class object (before class decorators are applied). Only a small change is made to super(): instead of making it a keyword, it can be invoked as a function without arguments, and then it digs around in the frame to find the __class__ cell and the first argument, and uses those as its arguments. Example: class B: def foo(self): return 'B' class C(B): def foo(self): return 'C' + super().foo() C().foo() will return 'CB'. The notation super() is equivalent to super(C, self) or super(__class__, self). It works for class methods too. I realize this is a deviation from the PEP: you need to call super().foo() instead of super.foo(). Looking at the examples I find that quite acceptable; in hindsight making super a keyword smelled a bit too magical. (Yes, I know I've been flip-flopping a lot on this issue. Working code is convincing. :-) This __class__ variable can also be used explicitly (thereby implementing 33% of PEP 3130): class C: def f(self): print(__class__) C().f() I wonder if this may meet the needs for your PEP 3124? In particularly, earlier on, you wrote: > Btw, PEP 3124 needs a way to receive the same class object at more or > less the same moment, although in the form of a callback rather than > a cell assignment. Guido suggested I co-ordinate with you to design > a mechanism for this. Is this relevant at all? -- --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
