[Python-3000] [Python-Dev] PEP 367: New Super

[Guido van Rossum]

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 <guido at python.org> 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 <guido at python.org> wrote:
> > On 5/27/07, Tim Delaney <timothy.c.delaney at gmail.com> 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/)