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? --Guido On 5/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Hi Tim, > > I've gone ahead and cooked up a tiny demo patch that uses im_class to > store what you called im_type. Because I don't have the parser changes > ready yet, this requires you to declare a keyword-only arg named > 'super'; this triggers special code that set it to super(im_class, > im_self). > > http://python.org/sf/1727209 > > I haven't tried to discover yet how much breaks due to the change of > semantics for im_class. > > --Guido > > On 5/27/07, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On 5/27/07, Tim Delaney <[EMAIL PROTECTED]> wrote: > > > Guido van Rossum wrote: > > > > > > > The bound method object isn't stored in the class -- it's created by > > > > the "C.method" or "inst.method" getattr operation. I don't see how > > > > this would introduce a cycle. > > > > > > > >> If we store the class, we can store it as a weakref - the when the > > > >> super object is created, a strong reference to the class exists. > > > > > > We need to create some relationship between the unbound method and the > > > class. So the class has a reference to the unbound method, and the unbound > > > method has a reference to the class, thus creating a cycle. Bound methods > > > don't come into it - it's the unbound method that's the problem. > > > > Still wrong, I think. The unbound method object *also* isn't stored in > > the class. It's returned by the C.method operation. Compare C.method > > (which returns an unbound method) to C.__dict__['method'] (which > > returns the actual function object stored in the class). > > > > > > Since class and type are synonym (as you say) having both im_class and > > > > im_type would be a bad idea. > > > > > > I'm struggling to think of another, not too complicated name that conveys > > > the same information. > > > > Keep trying. im_type is not acceptable. :-) > > > > -- > > --Guido van Rossum (home page: http://www.python.org/~guido/) > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > -- --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
