On 5/26/07, Tim Delaney <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > Quick, since I'm about to hop on a plane: Thinking about it again, > > storing the super instance in the bound method object is fine, as long > > as you only do it when the bound function needs it. Using an unbound > > super object in an unbound method is also fine. > > OTOH, I've got a counter argument to storing the super object - we don't > want to create a permantent cycle.
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 can't store a weakref to the super instance though, as there won't be any > other reference to it. > > I still quite like the idea of im_super though, but it would need to be a > property instead of just a reference. > > I also agree with Jim that exposing the class object is useful e.g. for > introspection. > > So I propose the following: > > 1. Internal weakref to class object. > > 2. im_type - property that returns a strong ref to the class object. > > I went through several names before coming up with im_type (im_staticclass, > im_classobj, im_classobject, im_boundclass, im_bindingclass). I think > im_type conveys exactly what we want this attribute to represent - the > class/type that this method was defined in. > > im_class would have also been suitable, but has had another, different > meaning since 2.2. Since class and type are synonym (as you say) having both im_class and in_type would be a bad idea. > 3. im_super - property that returns the unbound super object (for an unbound > method) and bound super object (for a bound method). > > Tim Delaney > > > On 5/26/07, Tim Delaney <[EMAIL PROTECTED]> wrote: > >> Guido van Rossum wrote: > >> > >>>>> - Why not make super a keyword, instead of just prohibiting > >>>>> assignment to it? (I'm planning to do the same with None BTW in > >>>>> Py3k -- I find the "it's a name but you can't assign to it" a > >>>>> rather silly business and hardly "the simplest solution".) > >>>> > >>>> That's currently an open issue - I'm happy to make it a keyword - > >>>> in which case I think the title should be changed to "super as a > >>>> keyword" or something like that. > >>> > >>> As it was before. :-) > >>> > >>> What's the argument against? > >> > >> I don't see any really, especially if None is to become a true > >> keyword. But some people have raised objections. > >> > >>>> Th preamble will only be added to functions/methods that cause the > >>>> 'super' cell to exist i.e. for CPython have 'super' in co.cellvars. > >>>> Functions that just have 'super' in co.freevars wouldn't have the > >>>> preamble. > >>> > >>> I think it's still too vague. For example: > >>> > >>> class C: > >>> def f(s): > >>> return 1 > >>> class D(C): > >>> pass > >>> def f(s): > >>> return 2*super.f() > >>> D.f = f > >>> print(D().f()) > >>> > >>> Should that work? I would be okay if it didn't, and if the super > >>> keyword is only allowed inside a method that is lexically inside a > >>> class. Then the second definition of f() should be a (phase 2) > >>> SyntaxError. > >> > >> That would simplify things. I'll update the PEP. > >> > >>> Was it ever decided whether the implicitly bound class should be: > >>> > >>> - the class object as produced by the class statement (before > >>> applying class decorators); > >>> - whatever is returned by the last class decorator (if any); or > >>> - whatever is bound to the class name at the time the method is > >>> invoked? > >>> I've got a hunch that #1 might be more solid; #3 seems asking for > >>> trouble. > >> > >> I think #3 is definitely the wrong thing to do, but there have been > >> arguments put forwards for both #1 and #2. > >> > >> I think I'll put it as an open issue for now. > >> > >>> There's also the issue of what to do when the method itself is > >>> decorated (the compiler can't know what the decorators mean, even > >>> for built-in decorators like classmethod). > >> > >> I think that may be a different issue. If you do something like: > >> > >> class A: > >> @decorator > >> def func(self): > >> pass > >> > >> class B(A): > >> @decorator > >> def func(self): > >> super.func() > >> > >> then `super.func()` will call whatever `super(B, self).func()` would > >> now, which (I think) would result in calling the decorated function. > >> > >> However, I think the staticmethod decorator would need to be able to > >> modify the class instance that's held by the method. Or see my > >> proposal below ... > >>> We could make the class in question a fourth attribute of the > >>> (poorly named) "bound method" object, e.g. im_class_for_super > >>> (im_super would be confusing IMO). Since this is used both by > >>> instance methods and by the @classmethod decorator, it's just about > >>> perfect for this purpose. (I would almost propose to reuse im_self > >>> for this purpose, but that's probably asking for subtle backwards > >>> incompatibilities and not worth it.) > >> > >> I'm actually thinking instead that an unbound method should > >> reference an unbound super instance for the appropriate class - > >> which we could then call im_super. > >> > >> For a bound instance or class method, im_super would return the > >> appropriate bound super instance. In practice, it would work like > >> your autosuper recipe using __super. > >> > >> e.g. > >> > >> class A: > >> def func(self): > >> pass > >> > >>>>> print A.func.im_super > >> <super: <class 'A'>, NULL> > >> > >>>>> print A().func.im_super > >> <super: <class 'A'>, <A object>> > >> > >>> See my proposal above. It differs slightly in that the __super__ > >>> call is made only when the class is not NULL. On the expectation > >>> that a typical function that references super uses it exactly once > >>> per call (that would be by far the most common case I expect) this > >>> is just fine. In my proposal the 'super' variable contains whatever > >>> __super__(<class>, <inst>) returned, rather than <class> which you > >>> seem to be proposing here. > >> > >> Think I must have been explaining poorly - if you look at the > >> reference implementation in the PEP, you'll see that that's exactly > >> what's held in the 'super' free variable. > >> > >> I think your proposal is basically what I was trying to convey - > >> I'll look at rewording the PEP so it's less ambiguous. But I'd like > >> your thoughts on the above proposal to keep a reference to the > >> actual super object rather than the class. > >> > >> Cheers, > >> > >> Tim Delaney > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
