Jim Jewett wrote:
> On 4/29/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
>> I've been intending to write up a PEP for fixing super, but I
>> haven't had time to get to it.
>
> Calvin Spealman has the most recent draft. I hope he will incorporate
> this into his draft.
Sorry about this - wasn't receiving python-dev at home, so didn't
realise Calvin had released the PEP.
I think the current PEP draft is way too complicated - I don't think
there's any need for descriptors, etc. I think we can make things work
in the following way:
1. When a method is defined, the class is bound to it via an attribute
(which in my version is called func_class).
2. Every non-static method has an implicit cell variable called 'super'.
This would preferably not be able to be rebound. I also think it would
be beneficial if the first parameter to the method couldn't be rebound
(point 7 in my original email in this thread).
3. When a method is entered, the 'super' cell variable is populated by a
call equivalent to:
super = __builtin__.super(func_class, first_parameter)
This would result in 'super' being a constant object, within the scope
of the currently-executing method. 'keyword' was perhaps too strong - I
was thinking this would only need to be done if 'super' were actually
used, which would be easier to determine if 'super' actually were a
keyword. This could still be done by not emitting the above call unless
the 'super' cell variable were ever actually used.
I've done bytecode-hacky stuff to do the equivalent of the above (as
much as I've been able to), but a real implementation would just emit
the correct bytecode (or java bytecode, or whatever) in the compiled
code object.
The issue of super() vs. super.__call__() ambiguity - I'll need to look
at that when I get home.
I'm a strong -1 against super() automatically passing the parameters
that were passed to the currently-executing method.
Tim Delaney
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
