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

[Tim Delaney]

Bah - this should have gone to Pyton-3000 too, since it's discussing the 
PEP.

Tim Delaney

Tim Delaney wrote:
> Guido van Rossum wrote:
>
>> - This seems to be written from the POV of introducing it in 2.6.
>> Perhaps the PEP could be slightly simpler if it could focus just on
>> Py3k? Then it's up to the 2.6 release managers to decide if and how
>> to backport it.
>
> That was my original intention, but it was assigned a non-Py3k PEP
> number, so I presumed I'd missed an email where you'd decided it
> should be for 2.6.
> We should probably change the PEP number if it's to be targetted at
> Py3K only.
>
>> - 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.
>
>> - "Calling a static method or normal function that accesses the name
>> super will raise a TypeError at runtime." This seems too vague. What
>> if the function is nested within a method? Taking the specification
>> literally, a nested function using super will have its own preamble
>> setting super, which would be useless and wrong.
>
> I'd thought I'd covered that with "This name behaves
> identically to a normal local, including use by inner functions via a
> cell, with the following exceptions:", but re-reading it it's a bit
> clumsy.
> The intention is that functions that do not have access to a 'super'
> cell variable will raise a TypeError. Only methods using the keyword
> 'super' will have a preamble.
>
> 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.
>> - "For static methods and normal functions, <class> will be None,
>> resulting in a TypeError being raised during the preamble." How do
>> you know you're in this situation at run time? By the time the
>> function body is entered the knowledge about whether this was a
>> static or instance method is lost.
>
> The preamble will not technically be part of the function body - it
> occurs after unpacking the parameters, but before entering the
> function body, and has access to the C-level variables of the
> function/method object. So the exception will be raised before
> entering the function body.
> The way I see it, during class construction, a C-level variable on the
> method object would be bound to the (decorated?) class. This really
> needs to be done as the last step in class construction if it's to
> bind to the decorated class - otherwise it can be done as the methods
> are processed.
> I was thinking that by binding that variable to Py_None for static
> methods it would allow someone to do the following:
>
> def modulefunc(self):
>    pass
>
> class A(object):
>    def func(self):
>        pass
>
>    @staticmethod
>    def staticfunc():
>        pass
>
> class B(object):
>    func = A.func
>    staticfunc = A.staticfunc
>    outerfunc = modulefunc
>
> class C(object):
>    outerfunc = B.outerfunc
>
> but that's already going to cause problems when you call the methods
> - they will be being called with instances of the wrong type (raising
> a TypeError).
> So now I think both static methods and functions should just have that
> variable left as NULL. Trying to get __super__(NULL) will throw a
> TypeError.
>> - The reference implementation (by virtue of its bytecode hacking)
>> only applies to CPython. (I'll have to study it in more detail
>> later.)
>
> Yep, and it has quite a few limitations. I'd really like to split it
> out from the PEP itself, but I'm not sure where I should host it.
>
>> I'll probably come up with more detailed feedback later. Keep up the
>> good work!!
>
> Now I've got to find the time to try implementing it. Neal has said
> he's willing to help, but I want to give it a go myself.
>
> Tim Delaney