[Python-3000] [Python-Dev] PEP 367: New Super (original) (raw)

Guido van Rossum guido at python.org
Tue May 29 04:37:47 CEST 2007

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 imclass and > > imtype would be a bad idea. > > I'm struggling to think of another, not too complicated name that conveys > the same information. Keep trying. imtype is not acceptable. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list