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
_______________________________________________
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
